[lsb-discuss] LSB confcall agenda: Schedule Details
Wichmann, Mats D
mats.d.wichmann at intel.com
Wed Sep 12 07:34:50 PDT 2007
> - LSB 3.2 schedule.
Here's some material for this topic, sorry this is
late given the volume of material here to digest.
Sorry this is also wordy, but there *are* a lot of
details to a release.
An LSB "Full Release" consists of these components:
2. SDK (bundled, individual packages)
a. lsbcc and header packages
b. appchk and pkgchk
3. Distribution Tests
a. individual functional test packages
4. Application Battery
5. Sample Implementation
Due to the LSB Workgroup procedure of keeping key specification details
in a database, the database itself is an invisible deliverable; while
not shipped as a "product" it generates information for (1), (2a-b) and
(3b). It is also used to generate another invisible deliverable, devchk,
which is generated code used to validate portions of the SDK.
Normally, we like to calculate two months for the completion of a
release. That is, we freeze the feature set and generate copies of
everything; then we have a month of cleaning up details in the
specification and getting the tools out into wider usage, followed by a
month period of "public review" which actually breaks down into three
weeks of review-and-respond-to-problems and a final week to prepare,
polish and test the final bits.
If LSB 3.2 releases in November, that gives a very rough timeline of:
* September - finish work on all outstanding features (more below)
* October ("Month One") - release preparation: complete details,
cross checks, initial external reviews
* November ("Month Two") - release candidates, formal public review,
prepare final release, conduct acceptance vote
Although it's not ideal, it's possible to blur the beginning of Month
One if the parameters are clearly understood and agreed. In the case of
printing and perhaps sound, it's almost certain we'd have to do this
which makes them not just new features, but somewhat risky.
We maintain an active nightly-build system, and it's partially
self-checking in that the build tools are generated, then used to build
the rest. For LSB 3.2 we finally got all of the test suites into this
system which really helps, as does the presence of the higher-level
abstractions DTK-Manager and ATK-Manager. Unfortunately, we have not
gotten the corresponding nightly-test system into production yet, which
prevents us from squeezing the cycle appreciably, as we must still
anticipate the possibility of "surprises" as the beta/rc test suites are
pushed into widespread testing.
1. Feature status
The main new features in LSB 3.2 are these:
a. addition of requested and missing interfaces to Core
:: in db/software, validating that specification is complete
b. addition of three new libraries to Desktop
:: in db/software; bugs remain in freetype library,
validating specification additions (known issues at the moment)
c. addition of four Freedesktop.org specification to LSB
as referenced specifications
:: specification text to be added; tests exist
d. perl and python as optional features
:: specification contents exist, need to be pulled into optional
e. addition of xdg-utils as optional feature
:: specification text to be added; tests exist
f. addition of printing interfaces
:: all database, specification, test work to be done;
some SDK work in place, some still to be done
In addition, one more item remains in "undecided" state
g. addition of sound interface library (as optional feature)
:: research still going on
Items a-e should be complete by the LSB Call on Sept 19. Timelines on f
and g are not firm at this point, unfortunately.
There's no mention here of the Qt4 question. There's only a small work
impact here if it switched from optional to required - a little database
work, tweak some meta-files for the specification, and regenerate a
bunch of stuff, checking to make sure it came out right.
2. Bug Status
There are a large number of open bugs in the LSB bugzilla which are
marked as blocking LSB 3.2 - currently 190. We maintain an "optimistic"
categorization approach, bugs tend to get categorized to the next
pending release unless there's a really good reason to know it needs to
be a long-term objective.
With a release target in sight, the buglist needs to be scrubbed and a
decision made on which bugs are truly must-fix for 3.2. Work on the
buglist is ongoing, so this won't take too long. Hoping to have the
final categorization complete by Sept 14.
3. Test Suite Status
There are several components to this:
a. Existing distribution test suites
:: These are in good shape except for a few known bugs.
In preparation for "Month one" we need to run the full suite on
several key distributions, on multiple architectures, and make
sure there are no unexpected results (this is a manual step for
now in the absence of auto-testing).
b. Tests for new features in existing libraries
:: work is ongoing, but there's no precise timeline. It's likely
that some new features will have tests available only after the
initial release of 3.2. We'll have to manage that situation, since
there's a risk of discovering an already-certified distribution
might not pass one of the new tests.
c. Tests for new libraries
:: for the three libraries already added, tests are already
integrated into the desktop-test suite (item a)
d. Improved tests from ISP-RAS
:: deliveries will begin late this year, so these are not
specifically targets of the 3.2 initial release; they may be
incorporated as part of the certification program later in
the cycle, however.
4. SDK Status
The SDK is believed to be in good shape modulo a few known bugs, and
there are no major discrete work items, except:
This is a chroot build environment which is constructed in a
method similar to the sample implementation. That is, a
collection of upstream packages with minimal patches are
built in a clean-room way that avoids distribution-specifics
(example of distribution-specifics: distros with new glibc
versions than the base version required by LSB will have
stack-check code inserted into static archives; the clean-room
build avoids this). buildenv is used as an alternative to
lsbcc for building.
Problem: nobody working on this, and it's effectively
unscheduled. It's not absolutely critical to have for
FCS of 3.2, as buildenv is not widely used, but it is on
the release checklist and so should be done.
b. SDK support for building for alternate versions of LSB.
We have a policy that developers target the lowest version
of the LSB they can for widest compatibility. The checker
tools are now multi-version; that is you can ask to check
for compliance with 3.0, 3.1, or 3.2. The same ability
does not exist for lsbcc (or buildenv). This would be a
nice feature to have but we've agreed it's not a release
blocker, and could be delivered later.
5. Application Battery Status
This work is complete except for one issue:
a. Make sure that each new LSB library is "touched" by an
application in the appbat. We already know that freetype
is used, have to check that Xft and Xrender have usage.
It is possible we will have to identify another app or
two to add for this purpose. If so, the work is only of
the order of a day or two.
6. Sample Implementation Status
There are some pending bugs which would not be too hard to fix, however,
despite the clean-room approach to building, several current
distributions are having trouble building the si so work that was
beginning has stalled. This needs to be reactivated. Since the sample
implementation is used for testing of applications, this is required to
be available with the other deliverables.
More information about the lsb-discuss