[lsb-discuss] Proposal on LSB "Optional" components
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.
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.
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.
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.
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
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