[lsb-discuss] LSB conference call agenda (Tuesday, November 14, 11am ET)

Robert Schweikert rjschwei at abaqus.com
Mon Nov 13 18:09:36 PST 2006


On Mon, 2006-11-13 at 15:46 -0800, Wichmann, Mats D wrote:
> >* LSB 3.1 Update 1
> >
> >We need to get this out soon. Let's discuss what needs to go in it
> >and timing. The main drivers here are 1. I want to get the waiver
> >fixes out there; and 2. we need to get a handful of things in
> >so that ISVs in the queue can certify (e.g., the ioctl for MySQL).
> >
> >Note that this brings up the issue of "update" policy, which we
> >hashed out on the workgroup call a few weeks back; for the benefit of
> >those who weren't on the call, the update policy is as follows:
> >
> >  From time to time, the LSB workgroup may issue updates to the
> >  LSB standard.
> >
> >  From the point of view of certified distributions and applications,
> >  the original version and the update shall be equivalent (i.e.,
> >  distributions and applications will certify to LSB 3.1, not LSB 3.1
> >  Update 1). In other words, recertification to an update is 
> >unnecessary.
> >
> >  To achieve this, no change will be made in an update unless the
> >  change results in all certified implementations remaining complaint
> >  after it is made--or, put another way,
> >  the original version is FORWARD COMPATIBLE with all of its updates.
> >
> >That's a little longer than I was hoping for, but I also want to
> >make sure it's precise. Suggestions on wording very welcome.
> >In the meantime, I'll make sure this finds its way onto the wiki.
> 
> That's not unreasonable.  I probably wouldn't use the word
> update (in the context of the spec), specifically, as it may
> imply more than will be happening. The piece that will affect
> ISO, at least, should probably called Technical Corrigenda to
> match terminology in use elsewhere. And it implies - which is 
> something we do anyway - that an addition has to be cast in terms
> of "it was an error that this item was omitted" rather than in
> terms of "we got a lot of requests for this, so we decided
> to add it".  I've had this conversation with Jeff on one
> issue, and I think it meets that criteria - there a few
> network-related ioctls that form a set, and we're missing a
> few items from that set, and I think we can claim it was
> an error to have left those out.   Just wanted to add
> those thoughts...

My concern is that one can always make the argument that something was
left out of a specific version of the LSB and therefore has grounds to
request inclusion in an update. Where do we draw the line? 

In principal I like the policy, just concerned about the large opening
this allows for getting new things into a released version of the LSB.
Maybe the policy should be more restrictive and focus on existing
libraries. (Not sure whether or not this would make ioctl drop out as an
option for 3.1 update 1).

Robert

> 
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/lsb-discuss
> 
-- 
Robert Schweikert                   MAY THE SOURCE BE WITH YOU
(Robert.Schweikert at abaqus.com)                 LINUX
ABAQUS Inc.
Phone : 401-727-4200
FAX : 401-727-4208




More information about the lsb-discuss mailing list