[lsb-discuss] [Lsb-infrastructure] LSB 3.1 Update 1 status (and minutesfor2/20 and 2/27)

Ian Murdock imurdock at imurdock.com
Sat Mar 3 05:39:38 PST 2007


Mats is right on the money.. For now, keeping optional modules away
from certification is the best approach. I want to keep the number
of possible choices small because of the combinatorial problem. So,
"optional modules" are really only guideposts on
what may be coming depending on which ones the distros adopt. -ian

On 3/3/07, Vladimir Rubanov <vrub at ispras.ru> wrote:
> Thanks, Mats, for clarification. So as far as I have understood - "Optional
> LSB Module" = "Candidate Module for future LSB versions". And it does not
> affect current certification at all. The approach of preparing candidate
> modules in advance is of course good, I was just misled by the term
> "optional".
>
> Thanks,
> Vladimir.
>
>
> > -----Original Message-----
> > From: Wichmann, Mats D [mailto:mats.d.wichmann at intel.com]
> > Sent: Friday, March 02, 2007 8:22 PM
> > To: Vladimir Rubanov; Ian Murdock; lsb-discuss; lsb-infrastructure
> > Subject: RE: [Lsb-infrastructure] LSB 3.1 Update 1 status (and
> > minutesfor2/20 and 2/27)
> >
> > Vladimir Rubanov wrote:
> > > Could anyone please describe what optional LSB module mean in terms of
> > > certification? Well, it is clear that we have specification
> > > and tests for optional modules. It is also clear that if an
> > > implementation does not support functionality from an optional
> > > module it is OK for certification. But what if it does support
> > > the functionality from an optional module? Do we require that
> > > it should behave as in LSB in this case (i.e. do we require
> > > passing the tests for optional modules for those distributions
> > > that support them)? What is the sense in writing specification
> > > and creating tests for optional modules in case we do not
> > > require anything about them?
> >
> >
> > you've put your finger on what has always been the issue
> > with anything "optional" in LSB - what does it mean for
> > people?
> >
> > Ian's crafted the current message there but essentially
> > it's best to look at optional modules as something which
> > clearly *will* meet our Best Practice criteria but does
> > not yet, usually because it's too early or out of cycle
> > for a few.  Case in point is indeed Qt4 - targeted at
> > LSB 3.1 which is supposed to run on RHEL5 and SLES10,
> > we were then told that RHEL5 wouldn't have the support.
> > This made Qt4 an optional module, to become mandatory
> > later.  Providing this specification early in the LSB
> > allows people to get a look at it, and possibly even use
> > it. It also allows us to get the work in and published
> > while the contributor is interested - if we'd waited
> > until today to start Qt4 work I'm not sure we would have
> > access to the resource that did the work as he was
> > foolish enough to get a promotion within TrollTech!
> > Ian likes to refer to this concept as "late binding" -
> > we do work as if a feature would go in, and at the last
> > possible moment decide whether or not to throw the
> > switch which marks it "required".
> >
> > There is no requirement on distributions; however,
> > we'd *like* them to say the also support optional module
> > FOO and applications using FOO would then run on that
> > distribution.  In the dtk-manager context, it would
> > actually have been easier if Qt4 was a separate test
> > suite rather than a runtime flag to the desktop suite.
>
>


-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige




More information about the lsb-discuss mailing list