CGL and the Linux Foundation

[dan@xxxxxxxxxxx (Dan Kohn)]

> Interesting; could you give us examples who disagrees with what?

The comments made to me have mainly been that CGL should focus on  
requirements, not implementations.  The what and why, not the how.

>> 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.

> 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.

> And test suites cost a lot of $$$ to develop, which is the main reason
> for current state of affairs in CGL. <sarcastic comment about the
> deep pocket's of LF deleted>

I hope to avoid sarcastic comments.  The LF is currently spending ~$1  
M a year to improve the test suites of the LSB.  We would be willing  
to dedicate resources for a carrier-LSB test suite, if necessary.

>
>> 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.

            - dan
-- 
Dan Kohn <mailto:dan@xxxxxxxxxxx>
COO, The Linux Foundation <http://www.linux-foundation.org>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>