[lsb-discuss] LSB 5.0 Road map -- It's a start

[Wichmann, Mats D]

I'm not sure more comment was needed beyond Robert's, but I'll do it
anyway.... :)

On Tue, Feb 7, 2012 at 6:28 AM, Robert Schweikert <rjschwei at suse.com> wrote:

> On 02/07/2012 05:36 AM, Dallman, John wrote:
>
>>  From the https://wiki.linuxfoundation.**org/en/ProjectPlan50<https://wiki.linuxfoundation.org/en/ProjectPlan50>wiki page:
>>
>>  While the enterprise distributions are the basis for the primary target
>>> "customers" of the LSB, third party software developers, it has been
>>> learned that the enterprise distributions do not re-certify a given
>>> release series to a newer LSB release. Therefore, the previous practice
>>> that caused the LSB to trail very far behind the leading edge will be
>>> abandoned for the next LSB release. This was a decision reached at the
>>> LSB F2F Spring 2011 meeting. For this next release the target is to
>>> strike a middle ground between "chasing" ever evolving community
>>> distributions, anticipating potential technology expected in the next
>>> enterprise distributions, and trying to make reasonable judgments about
>>> needs of the target "customers".
>>>
>>
>> I'm an archetypical example of those target customers: LSB already suits
>> what I do quite well, and makes my life far easier in supporting customers
>> running unexpected versions of Linux. While this description sounds good,
>> I'm unclear as to what it will mean in practice. Some specific questions:
>>
>> "anticipating potential technology expected in the next enterprise
>> distributions" seems to be fraught with peril. If a particular enterprise
>> distribution feels that some new technology is not adequately reliable, or
>> doesn't wish to support it for other reasons, then it being required by
>> a new LSB version is not going to change the distributor's mind.
>>
>
> All of this is still to be viewed under the light that the LSB is a
> trailing standard. The "trying to anticipate" statement is mostly targeted
> at our uplifts. For example SLES 11 SP1 ships with Qt 4.6, by the time SLES
> 12 is released we can anticipate that it will ship with at least the
> version of Qt that is in the current openSUSE release, a similar argument
> can be made for RHEL and Fedora. Therefore, there is no reason for us to
> restrict ourselves to stick to the number that is in the current enterprise
> distro.


The terminology "anticipate" indicates that it will be a quite educated
guess: three of the most prominent enterprise distros have a matching
community distro which is used to preview and more importantly mature new
technology.  At a particular moment in time we can look at non-LTS Ubuntu,
Fedora and OpenSUSE and have rather high confidence that the next
enterprise distro following that release will not have /older/ versions of
the components there.  It's not 100% science but the list of LSB components
that are subject to this sort of evaluation is small enough that we can
have very good confidence.  The wiki page Robert pointed to tracks this
(although we more efficient way of handling it:
https://wiki.linuxfoundation.**org/en/Uplift_Target<https://wiki.linuxfoundation.org/en/Uplift_Target>
)

I don't think this is making long-term distro support of LSB a more
difficult question, but an easier one.  An enterprise distro is going to be
happier with long term support (although of course they'll support it
anyway) of key pieces if the LSB requirement for that release closely
matches what they're releasing.  Let me try it with an example:  if Foobar
Enterprise is shipping glibc 2.14, and the LSB 5.0 requirement says "must
support the behavior of glibc as it was in release 2.4" that's a less
appealing support proposition than if LSB says "as of 2.13".  They'll
likely have to support older behavior anyway for other reasons, but at
least won't be saying "LSB is dragging us back" or more likely "LSB would
be dragging us back, so we don't really care about it".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20120207/65015a39/attachment.html>