[lsb-discuss] Time-based release for LSB 5.0 (sorta)

Jeff Licquia jeff at licquia.org
Mon Jun 13 07:36:16 PDT 2011

On 06/07/2011 09:00 PM, Craig.Scott at csiro.au wrote:
>  From an ISV perspective, I'd prefer to wait another couple of months for a LSB spec that is useful rather than have one "on time" which isn't really giving us much improvement. A major goal of the LSB is to provide a target to aim at. If that target is half-baked, ISV's will ignore it and then you'd have to question what the point of making the release was.

So, "better late than incomplete."  I think our past experience has been 
that "not late and complete" hasn't happened.

It's possible that there are other issues, though, like planning 
releases in December and not allowing for enough time in the freeze process.

> I generally agree with Robert's and Mat's comments regarding prioritisation. My own version of things would go something like this:
> (1) Get deprecation items sorted first. Things can be added later, but not so easily removed later. A x.0 release is the time to do removals.

I think we all consider that to be the top priority this go-round.

> (2) Revisit all trial use modules. Any that have been part of the LSB in that form for an appreciable amount of time should be either added as a first class part of the LSB or removed.

This one is easy: LSB 4.1 didn't release with any trial-use modules, so 
nothing to evaluate.  We may want to add a few, depending.

> (3) Identify things that "should have been in the LSB long ago". Of those, pick the ones that actually have a chance of getting done on a useful timescale. The harder/more complex ones can come in a later release. Everyone has different ideas of what "should have been in the LSB long ago", but there are likely to be some that have more general agreement.

We have the usual suspects, like D-Bus, uplifts to a few specs like 
OpenGL, and the RPM overhaul.  I'm sure I'm missing a few.

> (4) Are there any things that people have requested be added to the LSB and that don't have significant technical barriers? These would seem to be good candidates for inclusion in LSB 5.0. You could pick and choose based on how much time you wanted to spend on these.

We always have wishlist items and bugs.  New kernel features exposed in 
glibc are the most common.

Adding to this, I'd also include items for which we have significant 
external interest and resources.  SANE and the ARM port are two features 
that come to mind as examples.  These should probably be treated as 
optional "nice-to-haves" for LSB 5.0; if we get them done in time, good, 
otherwise they move to 5.1.

More information about the lsb-discuss mailing list