CGL and the Linux Foundation

[Joe.MacDonald@xxxxxxxxxxxxx (MacDonald, Joe)]

On Wed, 2007-09-05 at 06:31 -0700, Dan Kohn wrote:
> >> In short, we do think some things that CGL wants to see in
> >> carrier-grade Linux could best be implemented as LSB modules.
> >
> > Again, I would be interested in concrete suggestions.
> 
> My concrete proposal is that carrier-specific requirements should be  
> put in an optional LSB module, and that a comprehensive test suite be  
> written covering that those requirements are satisfied.  I'd like to  
> see CGL move to a certification, not a registration, model.

Personally I'd like to see this too, but certification carries with it a
whole extra level of validation (and possible liability) issues that the
CGL group at OSDL were unable to address.  I'd suggest that for the 4.0
timeframe we should stick to the registration process that Troy and Tim
had started assembling and that for the next version we look more
seriously at the costs and benefits of having a proper certification
process.

I really just don't want to do anything that will delay the registration
process for the 4.0 specification any longer than necessary, since the
specification has been out for going on three months now and there's
still no formal way for any distribution to claim compliance.

> > Umm, as far as I recall, requirement for the CGL distribution to be
> > LSB compliant has _always_ been a requirement. It might not have
> > been mandatory at some point because LSB _mandated_ things like
> > X, which make no sense in CGL scope. But we always accepted the
> > position of LSB as a required cornerstone on top of which CGL was
> > built on.
> 
> Actually, LSB 3.0 explicitly excludes X.  You can think of it as the  
> Server LSB, as opposed to LSB 3.1 being the Desktop LSB.

We had this very discussion a couple of times during the editing process
of the current specification and decided that we wouldn't name a
particular version of LSB but would instead call out the parts of LSB
that were important to CGL.  (See the description for STD.1.0 for what
we eventually decided on.)

> >> For our collaboration work, the large majority
> >> of our members have asked us to focus on running code (i.e., useful
> >> patches), and documentation.
> >
> > http://old.linux-foundation.org/lab_activities/carrier_grade_linux/ 
> > sprea
> > dsheet.html/ddocument_view
> > Go wild. Seriously, a lot of these project face serious issues with
> > upstream approval/integration, and that is the place where LF could
> > spend some thought/resources on thinking about the features these
> > projects try to address. I.e., if some implementation is deemed to
> > be unacceptable by the relevant Open Source project, then something
> > needs to be done, i.e. either improve the code or develop another
> > implementation. And usually the original implementor is unable/ 
> > unwilling
> > to do neither, but that does not mean that the feature is not needed.
> > So an akward stalemate situation ensues.
> 
> I see the LF playing more of a champion role than OSDL did.  However,  
> our main job needs to be to champion requirements with the kernel  
> community, not specific implementations.

I'm happy to hear the intent is for LF to be more active in supporting
CGL, and I'm thinking this is going to be a successful collaboration
once we get past this initial period of uncertainty, but as I mentioned
elsewhere, CGL needs to balance the needs of the carriers against the
abilities of distribution vendors to provide requirements without
compromising the value of the specification itself and what it means to
be compliant with it.  I don't think CGL should mandate a particular
technology solution, but I also don't think it should insist vendors
provide functionality that isn't already available in one form or
another from the open source community.  It's certainly not an easy job
we've taken on, but hey, if it was easy there'd be no need to do it in
the first place, all vendors would already provide a CG version of their
product.

-- 
Joe MacDonald <joe.macdonald@xxxxxxxxxxxxx>
Wind River Systems
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.linux-foundation.org/mailman/private/lf_carrier/attachments/20070515/c6280a25/attachment.pgp