[lsb-discuss] LSB 4.0 next steps

Alexey Khoroshilov khoroshilov at ispras.ru
Fri Jan 25 07:02:11 PST 2008



Wichmann, Mats D wrote:
> So whatever the precise details of releasing LSB 3.2,
> LSB 4.0 is going to be open for commits "pretty soon".
> We have not branched off to 3.2-maintenance yet, this
> might happen in five days, or ten, or whatever, but
> it seems not too early to bring this up.
>
> My assumption is that as soon as we've branched
> off 3.2 we will change all of the version-sensitive
> software in the "devel" branches to default to 4.0,
> which means that these will be pulling data from the 
> LSB specification database tagged as included for 4.0,
> and will eliminate anything tagged as eliminated in 4.0.
>
> There are at least three libraries that are ready to
> have at least some information go into the database:
> GLU, dbus and cairo (and actually, libpangocairo should
> go along with it). This will make them appear in bzr/
> snapshot versions of stub libraries, headers, checkers, etc.
>
> In addition, LSB Navigator would be updated to have the
> "4.0" menu possibility, and would default to 3.2,
> parallel to the current state where 3.2 is not the
> default, but is available.
>   
It is rather simple task:

UPDATE LSBVersion SET LVreleased ='Yes' WHERE LVvalue ='3.2';
INSERT INTO LSBVersion (LVvalue,LVreleased) VALUES  ('4.0','No');

As a result LSB 3.2 becomes the default version in the LSB Navigator as 
the greatest released version.
> Side effect: autobuilt packages will soon become
> useless for measuring/testing changes that relate
> to 3.2 issues. I would expect new material will
> be showing up by Feb 1 unless there's a major
> unanticpated delay that keeps all resources on 3.2.
>
> The other area is the specification.  Once new
> items go into the database, they can start
> appearing in generated specifications as well.
> In the beginning it will just be symbol lists,
> then it will grow to the full spec (either
> upstream references or spec wording in LSB).
>
> There are two possible approaches:
>
> a) generate full specs with the new material
> integrated.
> b) go back to the model that was used a few
> releases ago, and make available just a small
> book named WIP (Work In Progress).
>
> (a) has the advantage of being closer to releasable
> right away - things go into the place where they're 
> going to end up right off the front, and don't have
> to be put first one place, then later moved to another.
>
> (b) has the advantage of being able to have the
> evolving work in a single place where it's easy
> to find and review, and it's easier for the
> spec maintainer (currently me) to push one small
> book periodically than the whole set (which is
> 20-odd booksets).
>   
Full rebuild of the specifications for each fix in DB/sgml is definitely 
not suitable as well as postponement of the full build till the end of 
the release cycle.

First of all we need to setup a clean infrastructure for specification 
generation. It may include:
- finish transition between "lsbspec/book" and "books";
- add a concept of ModuleSet into LSB DB (ModuleSet = user visible LSB 
Module = bookset);
- update scripts to generate specifications on base of the LSB DB and 
the corresponding repository structure.

As for the specification development process I believe we should be able 
to generate the full bookset at any time by keeping all staff in the 
right place. Of course we can use some temporary Modules/ModuleSets if 
we do not come to decision where is the right place.

At the same time we could have parallel file structure and scripts 
allowing us to generate WIP book/bookset from different parts of the 
same (or almost the same) sources.

--
Alexey



More information about the lsb-discuss mailing list