CGL and the Linux Foundation

[mika.kukkonen@xxxxxxx (mika.kukkonen@xxxxxxx)]

>Behalf Of Dan Kohn
(...)
>Q. Does the LF care about CGL or is it letting it "wither on the vine"?
>
>A.  Yes, we want to improve Linux to better meet telecom customer  
>needs and to help win sales for network and telecom equipment  
>vendors, distros, and system companies.  Serving as a neutral  
>collaboration forum and helping shape consensus on critical issues  
>are both core parts of the LF's mission.  That doesn't mean that all  
>LF members agree with everything CGL has done or published in the  
>past, 

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

>Q. Aren't you just going to force everything to be part of the Linux  
>Standard Base (LSB)?  Aren't you shutting down former OSDL workgroups  
>so that the LF is just a renamed Free Standards Group?
>
>No, although I think Jim Zemlin and I are responsible for this  
>misunderstanding based on some of our comments that were taken out of  
>context.  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.

>Q. Isn't the LSB just a "bottom-feeding" standard that describes what  
>everyone has already agreed on?  Isn't it totally unsuited for CGL,  
>which is defining new requirements?
>
>No, just because the LSB isn't required for all CGL work, doesn't  

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.

>Q.  Will the LF support registration for CGL 4.0 compliant distros.
>
>A.  Yes, we already do, although it's not glamorous or rigorous.  Any  
>distro is welcome to update <http://www.linux-foundation.org/en/ 
>Registration> to register their compliance with CGL requirements.

Umm, that page does not contain anything that indicates that CGL 4.0 
registration is supported. The fact that it is a wiki and presumably
can be edited is not the same as a sentence saying "Registrations for
CGL 4.0 are now accepted."

>Q.  Will the LF promote CGL 4.0 registration?
>
>A.  It depends on the specific promotional request.   Brand building  
>is an expensive endeavor whether it is PR, advertising, trade show  
>support, logo development, etc. and we need to understand what the  
>goals for the CGL workgroup are here.   If those goals are in line  
>with the resources we can afford to allocate to this group, then we  
>can consider it.  In most of our work, the LF is more interested in  
>certification than registration, which generally means passing a  
>rigorous test suite. 

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>

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

>Q.  What do you think the CGL should be focused on?
>
>A.  At the end of the day, the CGL members need to reach consensus on  
>what they want to do.

"Reach consensus"? I have not seen any disagreements on this mailing
list;
could you be more specific?

>If SCOPE is willing, CGL should launch a joint effort over the next  
>several months to construct a gaps analysis document comparing the  
>key requirements from CGL 4.0 (and other critical customer  
>requirements that didn't get in the spec) with the state of the  
>latest distro releases.  Many of the CGL requirements are already  
>handled by the mainline kernel, and so are supported by every recent  
>distro release.  Some others are never going to get into the mainline  
>kernel or distros, and so whether they are really critical customer  
>requirements should be evaluated.  Other requirements are vague or  
>are useful for only a very small minority of carriers.

Sounds usefull.

>Q.  Isn't SCOPE a competitor?
>
>A.  Somewhat, but that's OK.  The majority of SCOPE members are also  
>members of the LF.  I have heard from several of them that they  
>wanted to break away from CGL because it was too telecom focused,  
>while SCOPE could address the needs of network equipment providers.   

I'm sorry, those last two sentences did not make sense; telecom focus
is what NEP's care about. Anyway, what I really would be interested to
hear was some position statement from LF's board. I recall that in the
New York meeting there were some pretty strong statements made by some
board members about the need to preserve CGL and it's achievements...

>Q.  When can we talk more about this?
>
>A.  Obviously, here on the mailing list.  But if SCOPE would invite  
>me to the meeting in Stockholm next week, I would be happy to attend  
>and get a chance to discuss these issues with all of you there.

I think this is being arranged as I write this. Sadly I'll not be there,
but I am sure enough of those who care about CGL will. Happy
discussions.

--MiKu