[lsb-discuss] LSB 4.0 next steps

Wichmann, Mats D mats.d.wichmann at intel.com
Wed Jan 23 11:13:00 PST 2008

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.

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
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).

By posting this message, I'm asking for feedback,
suggestions, comments, etc.  I particular, I'd like
to hear what people think about the specification



More information about the lsb-discuss mailing list