[lsb-discuss] notes from 2004-08-05 LSB meeting
Branden Robinson
branden at progeny.com
Mon Aug 9 13:01:14 PDT 2004
This past week, many of the major players in the Linux Standards Base
(LSB) organization had a meeting at the offices of IBM in San Francisco.
Because no person was available to take minutes for that meeting, and
because I needed to take notes for Jeff Licquia and Ian Murdock's
benefit here at Progeny, I volunteered to dual-purpose my notes as
meeting minutes.
A few caveats:
* I could not identify every speaker, so sometimes I wasn't sure of the
identity of who was speaking. Yes, I had the pleasure of meeting some
of these folks for the first time. :) Names were only spoken and I
could not read everyone's badge, so please accept my apologies if I
have mispelled your name, omitted part of it, or omitted it entirely.
* This meeting was continued on the morning of Friday, 6 August, but I
was unable to attend that session as I was catching a flight back to
Indianapolis at the time.
* There was a brief period (~5 minutes or less) after the 3pm break when
I was unable to take notes; Christopher Yeoh took notes at that time
instead.
* While in some places I recorded people's words close to verbatim, I
often summarized and condensed. Occassionally, issues I weren't
familiar with were discussed, and in the absense of context I may have
conjectured incorrectly as to what was meant. It is also possible
that I misidentified a speaker, though I don't think there are many
cases of that. In summary, these represent my best effort to document
the discussion.
My notes on the meeting follow. It was chaired by Mats Wickman and
lasted from approximately 1pm UTC-0700 to 4:10pm UTC-0700.
LSB 2.0 Meeting Notes
=====================
Stu Benedict (via confcall)
Christopher Yeoh
Ted T'so
Mats Wickman
Jim Zemlin (FSG XD)
Kevin ...
Matt Taggart
Karen Bennett
Chris ...
Kevin ... (Gelato)
Benjamin ... of Red Hat
Stuart ...
Tomas/Thomas?
Doug Beatty
Agenda items
------------
LSB 2.0 status
Release criteria
C++ issue
other issues
Roadmap for next releases
Target features
Test development
LSB shortcomings (what's missing)
LSB futures
Timing
Resources
Post-2.0 tasks
VSW4
Lsbsi cmdchk cleanout
Pkgchk, install-chk
Dynchk
Initd test/sample
LSB, lsbsi build environments
Plan for ISO
Web improvements
2.0 docs, developer docs
Doc for lib developers requested
What to do with out-of-scope requests
App uses non-LSB feature that won't be added (e.g. driver)
App uses feature potentially on roadmap
Subsystem dependencies (incl. Java)
Release Methodology
For LSB 2.0, we tried "big bang" release; does this work of should
we return to separate releases for (in particular) spec and test
LSB Certification Process
Reflections, Expectations, Improvements
Meeting
-------
Mats MCs meeting.
Dealing with seven architectures takes too much time; can we automate
better, do more autobuilding, etc.?
We've had offers of contributions that we've had difficulty making
something productive of. ("Why don't you just take this and work on it?")
Lists vs. conference calls. We use so many venues for talking about things
that it is difficult for new people coming in to catch up on how we think.
Need someone to take minutes. Branden volunteers.
LSB 2.0
-------
We've been working on LSB 2.0. Restoring threads, converting off our SUSv3
base, adding C++. We're here now rather than having released months ago
because we didn't get the testing lined out. How can we do that better?
Only one controversial issue: C++ ABI version.
No major screaming. A few noteworthy bugs but no release blockers.
Matt Taggart will give us an overview from the LSB website futures page.
We developed the selection criteria retrospectively after learning by
doing. We plan to have an issue (candidate) tracker for futures requests.
Want to move away from an arbitrary process to something better defined.
Phase 1: Fact-gathering:
* Must have sufficient demand.
* License. Must meet our "no strings attached" requirement. Not just
satisfy OSD, but be non-viral. I.e., no copyleft like the GPL.
* Best Practice. C++ experience has influenced this. Candidate must have
emerged as the de facto standard and actually be available. Controversy:
we mean best practice across all the deployed Linux Installed Base.
"Common practice" might be another term for this. But we're still trying
to capture the idea that this is the best way to develop for the
standard. E.g., gcc 3.4 is not yet in common usage.
* Stable ABI/API. Developers must be shielded from changes. We'd like to
write up a document describing best practices for versioning your
interfaces. Library versioning and symbol versioning. GCC is pretty
good at this but with C++ in particular there have been problems that
people did not forsee and avoid, leading to ABI problems.
* Dependencies present. Everything a candidate needs must already be in
the standard.
Phase 2: Investigation:
* Upstream cooperation. Example: great demand for standardized kernel
interfaces, but Linux kernel developers want the freedom to change
things.
* Distribution maintainers cooperative?
* Component versions? Are upstreams and distros willing to get synced up
on version numbers? Furthermore, have they not patched the heck out of
something such that the interface is affected?
* i18n: We've added this as a criterion. If it need to be i18ned, we do
this before adding it.
* Need someone to work on it.
* Rationale. We must capture why we want to add something to the LSB.
Phase 3: Implementation:
* We have a database of interfaces, so we can scan a library and add it to
our list. Import it.
* The written specification follows the actual interface implemented,
sometimes to people's surprise.
* Test suite.
* Development Components. C++ in particular required some additions here.
* Sample Implementation.
* Application Battery.
Final: once all 3 phases are met satisfactorily, we can add it to the LSB.
Matt demonstrates color-coded table on website showing status of various
real-world proposals.
Example, we have 2 candidates for C++
DB: What is the specification compared to the formal one?
MT: The specification is what was generated from the database, plus
human-added rationale notes.
D: How much work are we going to save in the end? The spec generated here
doesn't duplicate what we present in the final project?
MT: Some of the better candidates have some written specification done
before they come into the process. When we talk about "spec" we talk about
what comes out of the database. Ideally we have a candidate who has
totally defined the API and all we have to do is the ABI work. C++ and
IA-64 were a helpful case.
KB: The selection criteria are a new phenomenon? Not everything is green
for things going into LSB 2.0.
MT: We've been using this since after 1.2. We still have some things to
talk through. Every time we've skipped over one of the crtieria, it's come
back to bite us. One of the fuzzy cases is C++. Depending on
interpretation, some of its "yellow" requirements may be green or red.
MT: E.g., I have the c++ item's status as yellow. There's nothing terrible
controversial in the other two (FHS23, SUSv3).
MT: At the distribution level, nobody is shipping GCC 3.4 yet, and we don't
expect that everyone will have it for at least 9--12 months. We know some
distros will be shipping it sooner, but it will take time for it get widely
deployed. We all know that 3.4 is better, but waiting for it means
delaying C++'s addition to the LSB for many months. So an alternative is
to add C++ v5 now, and add v6 when it's ready.
KB: Who makes the judgement call on yellow, green, red?
MT: Since I'm the maintainer of the database, it's me, but we discuss these
things at meetings, conference calls. Yellow is something I use to
indicate that we need to discuss something.
MT: Should we go over the FAQ?
??: The FAQ is out of date.
TT: If we were to go strictly by the criteria, the consequence is no C++ or
no LSB release for a while. The reality is that ISVs are screaming for it.
Frank Witte ASP AG joins.
TT: One of the things we need to do a better job of bringing concerned
parties to the table is to include the stakeholders. ISVs, distribution
maintainers. C++ has been troubling b/c if we were to go by the strict
criteria, unlikely that we could come to all green in 12--18 months. This
is in an IT market where 2 years in infinity.
CY: In many cases the requirements are guidelines as well, especially for
old things already added.
MT: The spec represents the ideal situation. Very early on there were a
lot of things we added that had no test suite coverage, and our coverage is
still pretty low. We've realized that not holding ourselves to
TT: C++ is so critical that it behooves us to consider which items we can
tolerate being yellow or "orange" for the good of the whole Linux industry.
In the past we have been bitten when we go forward without meeting the
idea, but it may be our risk to manage. I suspect if we talk to some end
users or ISVs, they'll say "sign me up, we need this badly". We should
come up with a timeline that tries to sync everyone up as soon as humanly
possible. If that means give and take, that's what we need to do. I'm a
bit concerned that in the ideal world, we'd wait until everything is green,
but we don't have forever to get something that everyone can live with it.
KB: But that sets a precedent for going out with something less than all
green. We should have an exception model.
MT: Yes. This sort of thing is driven by a steering committee vote, but we
don't have full consensus yet, but we need to make a decision today or
tomorrow and move on.
??: Fully vetted voting procedures are an ISO requirement. I'm concerned
that we're struggling with fundamental issues.
TT: Let's think about what a roadmap might look like that convinces people
we're moving towards a better place.
MW: Yes, we ought to proceed with the standard we have now. We want to
know how we can evolve forward and get everyone synced up. Maybe we should
remove the C++ part from the ISO submission.
??: One thing that's come up would be to have an LSB core with a C++
addendum, exlcuding C++ from the core. We can continue to evolve the C++
module based on the GCC 3.4 v6 ABI and submit that as an addendum
?? of SAP: I'm responsible for the global Linux strategy. We are eager to
see standards out there that are not disadvantageous to any distribution
vendor. Once Volkswagen globally was at a standstill for four days. Not
every distribution has to be LSB 2.0 compliant. Customers are making
demands on us. What we hear from our customers, e.g. the German
government, is that the distributions need to be moving in the direction of
a standard, e.g. 3.0, sometime in the next year. We never want to come to
the point where we say the product we're developing on was not up to date.
We need to provide mission-critical-ready solutions. Sometimes big
customers, and big potential customers want us to referee among Linux
distributions. We don't want to do that. We don't sell Linux, Windows, or
Solaris. We sell SAP. If C++ is not is in LSB 2.0 today, fine. We are
ready to recode for 3.3 instead of 3.4 even though it will cost us coding
time. We are willing to wait for you to declare GCC 3.4 or 3.5 ready. It
is worse for LSB 2.0 to miss its deaadline because of what it says about
the maturity of Linux, than for LSB 2.0 to certify C++ v5 versus v6 or not
at all. With this external standard we want to provide an internal
development standard. This prevents embarassments after to deployment to
customers.
MW: We want to get LSB 2.0 very soon
??: Go with 3.3 ABI definition, start transitioning immediately to 3.3
B?: Does doing that make LSB 2.0 a lame duck?
MT: Ben how would support a 3.3.5 release?
B?: When that's released we can consider that a serious API.
KB: I think you've got a yellow now because the community objects.
TT: The standard that most of the community has used is that once
something's committed to a project's mainline, it's synced with the
community.
B?: We may have to agree to disagree.
??: We're not talking major changes for a 3.3.4 to a 3.3.5, just adding a
small set of symbols, and that's the only thing 3.3.4 is missing for LSB
2.0 compliance.
FW: We have to communicate that there are reasons for standardizing based
on 3.3.4 and 3.3.5. The main message is that we are working hard to
standardize. SAP is trying to help you communicate that this effort will
be recived well.
B?: We have definitely polled our ISVs about this issue.
KB: Red Hat has polled all of our ISVs to see if it is okay to go with a
standard plus a roadmap.
B?: If there is an FSG roadmap, I can help you determine where the GCC
Steering Committee is going. The plan for 3.5 or 4.0 whatever is to remain
ABI compatible with 3.4.
T?: We're a trailing-edge standard.
MT: We're trying to put a stake in the sand and tell ISVs to rally around
something. We're shielding them from the thrash of the development cycle.
The question with respect to GCC is, where do we do that?
TT: If 3.5 then becomes available in, say September 2005, and if we make an
exception for the 2.0/3.0 transition to happen in 1 year as opposed to an
18 month to 2 year cycle as we've planned for and GCC 3.5 gets barely
missed, is that going to be a big concern for GCC?
B?: No, because GCC's goal is to permit emission of different ABIs with a
given compiler, with GCC 3.4 as a basis.
FW: Maybe we could add that to the LSB itself, that the compiler be able to
emit the GCC 3.4 ABI.
B?: Right, that's what we're going to do for GCC.
FW: What about GCC/Itanium/64-bit issues? Our customers are concerned
about differences between the Intel and GCC compilers in terms of
compatible object interfaces.
B?: Intel's compiler defaults to the GNU runtimes now, and you can use free
software test suites.
MW: When might we see a couple of sample implementations so that we can
test?
B?: The betas of Fedora Core 3 are using GCC 3.4 as the default compiler.
MT: I don't think the issue here is how much effort it would take to get
the LSB up to the 3.4. It's distribution availability. It's going to be a
while before they do. Nobody is shipping a released distribution with it
right now.
MW: In a sense this is a question we can't answer for people (for the
distros). We can make our plans and shop them around.
MT: I have a proposal for the criteria. We need to know that 2 already
have actually shipped GCC 3.4 runtime support (not necessarily full
compiler) and 3 are planning to release it and all seek certification.
JZ: Let's work up the proposed roadmap tonight and get it out.
TT: Some of the test suite programs are dependent on data in the database.
We should find out where we need additional bodies even if for the short
term to get the database up to date.
B?: libcheck is working fine. Then there are the runtime tests that I
haven't look at yet.
Discussion of clash between ISVs who won't take LSB seriously without C++
and ISVs who won't take it seriosuly if it has two major releases in the
space of a year.
TT: Proposal: just because LSB 3.0 comes out doesn't mean that LSB 2.0 goes
away. To ease the pain for distros as well as ISVs, one of the things we
can do, given that this fast cycle will be a one-time event, we might waive
the certification fees for 3.0 for those who certified during the fast
cycle window. I've talked to a couple of FSG board members and they're not
alarmed.
?? SuSE: But we can't install multiple lsb-release commands at once.
CY: Actually that's a bug in lsb-release.
TT: We want to allow a distro to support multiple versions of the LSB and
advertise that with the lsb-release command.
MT: Could we call it LSB 1.4 instead without the C++ stuff?
S?: Too many other changes.
[...CY took notes after a brief break]
The
FW: Question from SAP, so the chances are even better for us that once LSB
3.0 is out that we can easily support Mandrake? We want to ease our
internal work but also support as many distros as possible.
PHONE:
FW:
PHONE: We pretty agressively follow the new GCC.
MT: We heard earlier that 3.5 is not going to be until Q3 or Q4 of 2005.
FW: So if we start with 3.4, we won't have a problem with 3.5? I can take
that home?
B?: Yes.
MT:
Stuart presents a proposal for LSB 2.0 vs. LSB 3.0 that he and Nick came up
with.
What we have right now is LSB core and the graphics module that form that
makes up the certifiable entity. We think we're going to pull the v5 (GCC
3.3) C++ chapters out for ISO, but from the FSG's perspective C++ is part
of the standard. But for LSB 3.0 we will update the C++ module with
respect to 3.4, and there will be various other updates.
In the LSB 3.0 timeframe, the ISO submission is the same core -- we've
gotten some feedback and made some editorial corrections. But we'll add on
the separate C++ addendum, which will be on a separate ISO ballot. (The
ISO ballot process is 6 months).
TT: The addendum is *just* the C++ as of GCC 3.4 material.
S?: Another strategy we talked about was that we want to send the SECOND
version of things to ISO, not the first. This proposal is consistent with
that. The core plus graphics in 2.0 are the second version. What we
submit to ISO as the C++ addendum will be on its second version by then.
S?: Another 3.0 thing is that it sounds like we might try to define a bit
more what the development environment is like. E.g., using shared
libraries from different sources.
TT: But this would be an LSB 3.1 thing?
MT: Or even a different FSG standard.
CY: This was going to part of the original LSB, but it was too big a job
and dropped it.
S?: We've got half of a test for that already, but the runtime stuff has
come to consume most of our attention.
MT asks S? to write "NOW" and "Q105" under the diagrams for LSB 2.0 and LSB
3.0, respectively.
Consensus is sought and achieved that the
S?: Enhancing the tests will enable us to enforce the ABI consistency
MT: I propose some additional dates. If we were to release the LSB 2.0
spec today, the drop dead date for ISO submission in 31 October. Try to do
the submission to ISO on 1 October.
N?: Once it gets to ISO, there is a six-month ballot while it is considered
by the national standards bodies. ISO sets the date.
N?: At 6 months + 1 day, we get word back from the ISO Secretariat
reporting the votes and comments. Most attention is given to what we
submit is the explanatory report that details how we're meeting ISO's
criteria. We will need to go through and address every single comment that
comes through. We either accept or reject each comment. That period is
over when we say it's over. We then submit the disposition of comments
report. I think after that it is adopted or not depending on how many
"yes"s and "no"s there are. Typically we have 1--2 months to respond to
the comments.
N? discusses Technical Corrigenda vs. Document Revisions vs. Addenda. We
should keep the LSB 3.0 core as close to 2.0 core as possible. Stick to
technical corrigenda as much as we can get away with.
MT: Down the road though, we'll have to do a document revision.
N?: Yes. It may be that LSB 3.1 contains the ISO-approved 3.0 core and C++
addendum, plus any feedback we get and any futures items that have passed
muster. Usually you get comments about not explaining things well; I don't
expect comments on ABI issues.
KB: Have you not been soliticing coments from the geographical
organizations?
N?: Yes, and we've gotten nothing.
TT: We followed up with an another appeal for comments in Tokyo in
February.
N?: We've had zip formal comments. We've had informal comments from some
countries saying "get on with it"!
JZ: We're incentivized to move things along.
FW departs.
MW: Did you have different feedback?
B?: I think this would probably go over better than your draft.
KB: Maybe this new plan changes the dynamics of what people will think.
B?: People wanted modularity, and you've addressed that.
T?: Put the proposal out there; how long do we wait to start the 3.0
process?
CY: My feeling is that the quality of the test suites is sufferning because
we've been going after this "Big Bang" approach. I suggest waiting at
least one month after the specification release before we release the test
suite.
TT: The spec has to really be locked down before the test suite release.
Can we better resource the test suites, putting more people on them so that
we don't run into this crimp.
CY: I think we need more time and focus on stabilizing the tests.
MT: Often we'd run into test suite deficiencies, so if we'd delay the
release spec until the test suite were ready, that would cut down on
certification frustration.
S?: Every time, the test suite has turned up bugs in the spec.
MT: I propose writing up this proposal and timeline and getting it out by
the end of the week. We want to give the GCC guys among others time to
comment on it.
Certification Issues
--------------------
MW: We have a question before us about how well certification is working.
??: It should be easier to clone data for submission to the web site. The
Open Group system still suffers from many bugs. The biggest problem was
that payment for 7 certifications at once wih a credit card was impossible.
You furthermore can't use multiple credit cards for submitting multiple
certifications.
N?: It should be a P.O./invoice model.
MW: It's done the way it is to hold costs down.
MW: Has uptake been what we wanted? For me personally, not quite. For
some people it's a cost issue. Some people do their conformance stuff and
just wait for a customer to tell them a sale depends on the certification
to actually do it. 40 products, 10 companies.
JZ: More are going to be willing to step up as we move forward.
MW: One thing we'd love to see is Debian.
MT: We haven't had a released product to submit. But we will, and it will
happen.
JZ: We could do some more outreach to get people interested and get it
growing.
D?: Application cert uptake is mostly blocked on unsepcified libraries.
C++, desktop. Also, what's our Java story?
JZ: I'm thinking we need to start a 2--3 year roadmap undertaking market
research, finding out what ISVs and distributions are wanted.
MT and TT discuss drilling down and polling packaged applications to
determine their library dependencies.
JZ: I'd like to volunteer to systematically rank who to talk to and
determine their requirements. We have a full time guy to make the
contacts.
Meet back here tomorrow at 8am (some groaning). Running until noon.
vim:set ai:
[end of notes]
I strongly encourage attendees and others to post corrections to these
notes to the mailing list.
As a final note, It was an honor and pleasure to watch the LSB at work.
I know you folks had a particularly difficult issue to wrestle with for
this meeting, but it was very encouraging to see a technical working
group dealing with it so productively. I can think of one or two
projects to which I belong that could learn from your example ( ;-) );
I'll certainly try to do so myself.
--
Branden Robinson | GPG signed/encrypted mail welcome
branden at progeny.com | 1024D/9C0BCBFB
Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C
| 72E8 0F42 191A 9C0B CBFB
More information about the lsb-discuss
mailing list