[lsb-discuss] Proposal on LSB "Optional" components

Robert Schweikert robert.schweikert at mathworks.com
Tue Oct 9 08:53:56 PDT 2007


Picking this up again, I think we need to move this along. Using the 
concepts Mats indicated I propose the following definition:

LSB Trial Use Module

An LSB trial use module is considered to be part of the LSB on a trial 
basis. LSB compliant systems are not required to provide the interfaces 
specified in a TUM (Trial Use Module), thus applications must perform 
install testing or other testing to assure no adverse behavior if 
dependency on a TUM exists.

1 Motivation
Trial Use Modules allow the LSB to indicate which interfaces are under 
consideration for future inclusion in the LSB. This helps distribution 
vendors w.r.t. setting a direction for future relases, and it helps ISVs 
by indicating which interfaces have a potential for inclusion providing 
the opportunity for a better understanding of system dependencies.

2 Usage conditions
2.1 Distribution version discrepancy
A TUM may be added to the LSB to convey that existing current 
distributions have version discrepancies for the interfaces specified in 
the TUM. This allows the LSB to encourage distribution vendors to 
converge on the interface version specified in the LSB TUM while giving 
distribution vendors sufficient time to move toward the common interface.

2.2 Testing the impact
A TUM may be added to the LSB to encourage feedback from users and 
distribution vendors. Additionally this provides the opportunity for 
upstream developers to voice their concern if interfaces are being added 
which are deemed private or unstable by the developers. This feedback 
will allow the LSB to document the concerns.

3 Lifetime
Once a TUM is added to a version of the LSB further action will be 
required prior to the next release of the LSB. The status of the TUM may 
be determined to be one of the following options:

1.) The TUM now fulfills all requirements of a regular module and is 
therefore ready to be accepted into the next version of the LSB. 
(lifetime 1 release).
2.) The TUM is not ready for inclusion in the LSB as a required module. 
Reasons for this need to be documented. At this point the TUM lifetime 
may be extended for one release.
3.) The TUM is dropped, i.e. it is removed from the next LSB version.

A TUM should not be re-introduced after it has been dropped.

4 Testing
A TUM is expected to have a level 1 test suite. The test suite is 
enabled by default in the LSB distribution test kit. Test results for 
the TUM will be reported separately from the LSB compliance test 
results, but will be posted to the LSB web-pages to make the information 
available to interested parties.

-----

Maybe we can use this as a basis for discussion during tomorrows call or 
the f2f next month.

Robert

Wichmann, Mats D wrote:
> Okay, it's not really a full proposal, just the
> thoughts that I mentioned on the call last week,
> spread out for wider consumption in advance of
> this week's call and for list discussion.
>
>
> It's my feeling that the LSB concept of providing
> optional modules is somewhat unclear to people.
>
> Starting with LSB 3.1 we added a concept of Optional
> Modules to the LSB.  These were ones which were not
> ready to be full required components of the LSB
> for some reason.  We envision these as generally
> being features which are not controversial, but
> are not yet shipping (or perhaps not at the right
> version) in the distributions which are a target
> for that LSB version.  By publishing them as
> optional, we give people a chance to use them
> and be ready for when they do become required.
>
>
> I'm suggesting these two tweaks to this scheme -
> they're not really big changes.
>
> 1. rename this concept as Trial Use Module (or
> some similar name). I believe this conveys more 
> of the transient intent than the term Optional.
> We don't intend to introduce a lot of features 
> which will remain Optional for a long time;
> optional features are hard to use because you
> can never count on distributions to implement
> them, since they're not required to.  Trial
> Use, to me, suggests more of a path of "this
> is experimental, but it's on the way in unless
> people find it unacceptable".
>
> 2. require a Trial Use Module to be formally
> renewed by vote for each LSB release.  The vote
> could have three outcomes: ready to go in as
> a fully required feature; renewed as a trial
> use module; or dropped.  This forces features
> to progress to their intended state in a timely
> fashion, or else go away.
>
> Note that it was suggested on last week's call that
> there might be a limit on number of renewals,
> with one renewal proposad as the maximum.
>
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
>   

-- 
Robert Schweikert                       MAY THE SOURCE BE WITH YOU
(robert.schweikert at mathworks.com)                 LINUX
The MathWorks Inc.
Phone : 508-647-2042






More information about the lsb-discuss mailing list