[lsb-discuss] LSB confcall agenda: Schedule Details

Vladimir Rubanov vrub at ispras.ru
Thu Sep 13 01:48:25 PDT 2007


I would like to add some points from ISPRAS side.

1. By the end of September, we are going to release new tests for the 4
existing libraries - libfontconfig (~150 interfaces), libatk (~220
interfaces), libglib (~830 interfaces), libgmodule (8 interfaces). The tests
will cover almost 100% of interfaces in these libraries (leaving only
undocumented).
   a. One issue here is that our tests do find inconsistencies with LSB in
modern distributions. We are going to work with the corresponding upstreams
to fix the problems but I wonder how long it would take to really include
the fixes into the new distribution versions. So I am not sure we should
include the tests into the official certification suite for 3.2 even though
they would be technically ready. Opinions?

2. We are working on the new certification system (central web part
leveraged by locally run dtk/atk managers). Hopefully we will deploy the
first version by the end of November to allow LSB 3.2 certification in this
new system. Prototype is ready, next alpha version will come at the
beginning of October.

3. One component of LSB not mentioned is LSB Navigator which we release
regularly. Usually it is bound to LSB Database releases. The nearest version
will come by the end of September, and then we'll enter the regular "QA,
improve and polish" cycle like with the entire LSB 3.2 to deliver 3.2
synchronized major release at the end of November.

4. An analytical thing we need is to update test coverage info in the DB
regarding all the new tests. We'll take care of this.

5. Regarding nightly distribution tests execution. We have prepared all the
technical things in DTK Manager to enable command line execution and
automatic results upload to a remote server (see
http://ispras.linux-foundation.org/index.php/LSB_DTK_Manager_Nightly_Run_HOW
TO for details). So the first step is ready. Is someone planning to use this
for actual LF test farm construction? Or for building distributed test farm
with tests being run at distribution vendors' side and then collected at a
central LF server for analysis?

Regards,
Vladimir.



> -----Original Message-----
> From: lsb-discuss-bounces at lists.linux-foundation.org [mailto:lsb-discuss-
> bounces at lists.linux-foundation.org] On Behalf Of Wichmann, Mats D
> Sent: Wednesday, September 12, 2007 6:35 PM
> To: Jeff Licquia; lsb-discuss
> Subject: RE: [lsb-discuss] LSB confcall agenda: Schedule Details
> 
> 
> > Agenda:
> >
> >  - 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:
> 
> 1. Specification
> 
> 2. SDK (bundled, individual packages)
> 
>   a. lsbcc and header packages
>   b. appchk and pkgchk
>   c. lsb-buildenv
>   d. atk-manager
> 
> 3. Distribution Tests
> 
>   a. individual functional test packages
>   b. libchk
>   c. dtk-manager
> 
> 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.
> 
> 
>   Timeline
> 
> 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.
> 
> 
>   Timeline Details
> 
> 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
> module set
>   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:
> 
>  a. lsb-buildenv
>     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.
> 
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss




More information about the lsb-discuss mailing list