CGL and the Linux Foundation

[joe.macdonald@xxxxxxxxxxxxx (Joe MacDonald)]

Hi Dan,

It's good to hear from you and I can't speak for anyone else, but I
appreciate you taking the time to put together such a detailed response
to the various issues that have come up on the mailing list over the
last little bit.

I'd intended this email to be a lot shorter than it turned out to be, so
I'll cut right to the chase.  It's reassuring to hear that LF is
interested in continuing CGL, I think everyone on this list thinks CGL
still has an important role to fill.  I think the concern came from the
silence that fell immediately following the announcement about the
formation of the Linux Foundation, which was probably a combination of
the CGL working group just being exhausted from finishing up the spec
and everyone wanting to see what LF would have to say in the days
following.

Now the more detailed bits.

On Tue, 2007-01-05 at 11:35 -0700, Dan Kohn wrote:

> 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, but I can assure you that the LF wants CGL to continue, that  
> you can count on me as your contact point for working with the LF,  
> and that we are willing to dedicate resources for CGL's success.

I'm glad to hear that, because despite some of the press coverage about
the 4.0 CGL spec being little more than a minor revision of 3.2, I think
it was a significant improvement in both content and in terms of
defining what CGL really means.  As one of the section editors this time
around I'm probably a bit biased, but I'd be happy to enumerate the many
ways 4.0 improves 3.2 for both distribution vendors and companies that
are trying to pick a distribution.

I will say, though, that my impression is that we were in the home
stretch of getting the 4.0 spec out when news about the Linux Foundation
broke and it seemed to take a lot of the wind out of our sails.  Not in
a demoralizing way, I don't mean it to sound like that, but that we had
finished the documentation reviews and were turning things back over to
OSDL to handle the steps of publication of the documents and the
reference implementation database and to handle providing the
infrastructure necessary to handle registrations going forward.
Everything seemed to get a bit uncertain for a while there (it could be
argued that it's still uncertain, but I take your mail as a sign that
things are clearing up) and our ideas about a registration process
seemed to languish since we hadn't even been able to publish our PoC
database with the release of the specification.

If I'm wrong on that point, please correct me, too.  I sort of feel like
I've been out of the loop the last few months, so I might very well have
missed some announcement, but that's the view from here.

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

This could very well be the case, that a lot of the coverage in the
press at the time seemed to be coming from a few interviews and other
articles and it probably had elements of a game of Telephone going on.
To be fair, though, I went back to review the LF press release from
January 21st and it says (paraphrasing a bit):

   The Linux Foundation?s Activities

   The Linux Foundation does not build Linux, nor does it compete with
   existing Linux companies. Rather it fosters the growth of Linux by
   focusing on the following areas:

       - Protecting Linux by sponsoring key Linux developers and
         providing legal services [...]
   
       - Standardizing Linux and improving it as a platform for software
         development
            [...] These include the Linux Standard Base (LSB) and the
            Linux Developer Network.  All major Linux distributions
            comply with the LSB.
   
       - Providing a neutral forum for Collaboration and Promotion
            [...] It also fosters innovation by hosting collaboration
            events among the Linux technical community, application
            developers, industry and end users to solve pressing issues
            facing the Linux ecosystem in such areas as desktop
            interfaces, accessibility, printing, application packaging,
            and many others.  


You can probably see how this sounds a lot like the new organization is
primarily focused on helping people who produce the code first (which
I'm all in favour of), then using LSB as the vehicle for standardizing
Linux platforms and finally encouraging collaboration on largely
desktop-oriented areas.

> In short, we do think some things that CGL wants to see in  
> carrier-grade Linux could best be implemented as LSB modules.   
> However, there's lots of other work that the LF is supporting that  
> has nothing to do with the LSB.  In particular, if we can find  
> specific gaps in kernel or package functionality, we would be willing  
> to fund developers to write patches that would then be submitted to  
> those projects.

I certainly wouldn't argue against something like this, but so far CGL
hasn't been focused on gaps and adding functionality to the kernel.  My
understanding was that CGL's goal was to identify pieces that
distribution vendors must have in order to be reasonably called Carrier
Grade.  That way when someone is picking a distribution to run on their
equipment, they have a reasonable expectation that any Carrier Grade
distribution has a set of core functionality and they can made their
decision on other criteria (vendor relationship / reputation, value add,
specific hardware support, etc.).

The CGL 4.0 spec has roadmap items, saying these are things that either
the CGL group or other groups (SCOPE for example) have identified as key
but don't currently exist or can't reasonably be called stable yet.
It's important to remember, though, that one of the key criteria for any
4.0 requirement to be a P1 was that there had to be a freely-available,
portable, widely-accepted proof-of-concept implementation available
today.

Do you have specific things the CGL working group did that you can see
as clearly separate from the goals of LSB?

> 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  
> mean that it can't be useful.  The LSB supports the concept of  
> optional modules, where new functionality can be specified that is  
> not yet "best practice" -- i.e., is not yet shipping in the major  
> distros.  This is described in the LSB Charter <http://www.linux- 
> foundation.org/en/LSB_Charter>.

I need to re-read the charter in more detail, but the last line in the
section on the scope of the LSB seems to highlight the difference
between that and what CGL had been attempting to do:

        In practical terms, this means that the technology is shipping
        in all major Linux distributions; has an ABI that is deemed
        stable over the long term; and has sufficient demand for
        inclusion among the key stakeholders.

That's not exactly an opposing goal to CGL, but it's easy to think of
areas where specific parts of the CGL spec would necessarily fall
outside this scope.

I think perhaps it would be worth defining the scope of CGL separate
from LSB would be a good idea, based on the guidelines laid out for the
CGL WG when it was a part of OSDL.

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

This is specifically for 2.0 and 3.2 specs, from my reading, which had a
relatively lax registration process compared to what our sub-group had
been discussing in Portland and Alameda last fall.  I think what we need
to do now, and what we've started touching on here in the last week, is
assemble a 4.0 registration process -- one in line with the goals we
agreed on in the fall face-to-face meetings -- and find out the level of
commitment LF would have to supporting it.

To draw attention to one point in particular, prior to 4.0 it wasn't
necessary to have all P1s in your distribution in order to register.
That's a fundamental change in 4.0, that any distribution must include
some implementation of all P1s in order to claim CGL 4.0 conformance.


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

I've got to admit, this is one of the things I was most excited about
when I first heard the news about the creation of the Linux Foundation.
I think this is a great opportunity for us to work together to really
create a coherent message that will communicate the goals and the value
of CGL to the community at large.  I think the sort of dialogue that has
started on the mailing list here is a great first step.

> Q.  What do you think the CGL should be focused on?
> 

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

I'll let others speak to this, but I'm pretty confident that just such a
process is happening right now.

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

This is all good feedback, and speaking as someone who implements these
features in a distribution, I can tell you that I've already got marked
up copies of the 4.0 spec on my desk where I see room for improvement.
I'd been meaning to share this with the group for a few weeks now but
other things kept coming up.  I'll be sure to share my notes with
everyone very soon, though.

> If we can then identify a few specific, actionable gaps that can be  
> addressed with a reasonable amount of focused activity, the LF can  
> probably fund a developer or two to do specific projects.  We can  
> also coordinate among CGL member companies working to improve  
> different areas.

We did have some specific gaps in the 4.0 spec that we would really like
to see addressed.  The meeting in Portland in the fall generated a list
of critical SCOPE items that we were forced to mark as P3 items simply
because there was no implementation that met our requirements for being
a P1 or P2.  We'd obviously need to discuss with SCOPE again to make
sure we have the right items at the top of our list, but this is
something we could probably turn around to LF fairly quickly.

Anyway, that's all I have, which I'm sure is more than many had hoped to
be reading.  :-)  I'm looking forward to working with all the prior CGL
members and with the new team at LF and I hope to see you all in June.

Thanks.

-- 
Joe MacDonald, Member of Technical Staff, Linux Products Group,
Wind River -- direct 613.270.5750  fax 613.592.2283