CGL and the Linux Foundation

[jjg@xxxxxx (John J Grana)]

Dan,
        Thanks for some of the clarifications and suggestions/comments for 
moving forward. I would hope that as the CGL group begins the course on 
CGL 5.0 (or some number > 4.0), we consider things like LSB module's and 
even - certification as the goal. Good ideas! For now, there is still the 
looming issue of completing the CGL 4.0 process.

With that said, can I be so bold as to begin a thread on discussion 
revolving around the registration process for 4.0? This might wander a 
bit, but I thought I would at least get the ball rolling by throwing out 
some ideas/strawman/suggestions....

We (PTI) registered under 3.2 with the help of Bill Weinberg. As we 
started the registration, Bill told me he wanted us (PTI) to be a beta of 
a potential way to better register future CGL implementations. Here is an 
outline of what occurred (interspersed with some comments from me!). Most 
of this is coming from my memory - and I must warn that I don't have 
ECC....

1) The base registration document is a lengthy HTML document that shows 
each and every P1 and any P2 the register feels should be included in 
their distribution. The HTML is layed out in such a way to cover each main 
section of the CGL requirements document - so it attempts to match up the 
requirements one for one.

MY comments - we (PTI) used a spreadsheet to track and comment our 
progress as we added modules etc. to meet the requirement's. One idea is 
to have CGL produce a spreadsheet already enumerating all P1 and P2 along 
with columns for check off and one or two line comments.

2) The HTML registration document (and possibly the much shorter 
spreadsheet) are filled out and submitted by the vendor to the CGL "group" 
for review. The HTML doc shows in detail what software was used to meet 
the various requirement's. Like past registrations, the vender needs to 
explain how the requirement was met, and the "Name/Vendor/Open Source 
Project" that the software was taken from. The CGL 3.2 Registration 
Document, section 5 covers this quite well. I also liked the listing of 
all source and header files. If the vendor uses in-house developed 
software, then that software must be listed and/or displayed. We had one 
module that we used so we included a full source listing.

The HTML file is also important since it is the method used to show via 
various web sites, what is in a vendors CGL registered distribution. So, 
it must all be public.

3) A technical committee reviews the submitted documents. In our case for 
CGL 3.2, it was Peter Badovinatz, Bill and (from what I can recall) 
Terence Chen. In our case, Bill coordinated the comments from Peter and 
Terence (questions on some of our implementation decisions) and sent them 
back to us for response. We responded, our response was again reviewed.
This review I believe was meant to insure that all of the requirement's 
were met in a rational fashion. Some good questions came back!
As far as P2 - we implemented a number of them. Some we (PTI) felt 
important for our product and frankly some we did as a "strategic 
advantage" ;-)

In any case, after this review period - which took approx. a month - we 
were giving "registration approval".

4) After registration approval - we then posted the HTML registration 
document, press released, had a party, got a license plate etc.

In the end, I felt the review by Bill, Peter and Terence was well 
worthwhile. And also made my team here a PTI feel they really DID meet a 
specification or requirement's are whatever we call this. It was good and 
worth it!


So, long winded summary -

 Actual certification by an independent group is a great goal. Difficult 
IMHO (just ask the CP-TA group...) but a good future goal. One that needs 
to be known as we start a new version.
Encapsulating P1's (at a minimum) into  a single LSB module is also a good 
idea - but again needs to be taken into account at the start of the 
requirements definition session.
The CGL 3.2 process as documented (March 2 version) was a good step
For 4.0, I would add a technical review team. I would also have the 
technical reviewers sign off on the HTML document and be included in it 
somewhere.


My $0.02...

Cheers
John Grana






Dan Kohn <dan@xxxxxxxxxxx> 
Sent by: lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx
05/09/2007 09:31 AM

To
"<mika.kukkonen@xxxxxxx>" <mika.kukkonen@xxxxxxx>
cc
lf_carrier@xxxxxxxxxxxxxxxxxxxx
Subject
Re: CGL and the Linux Foundation






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

_______________________________________________
Lf_carrier mailing list
Lf_carrier@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/lf_carrier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.linux-foundation.org/mailman/private/lf_carrier/attachments/20070510/f17cca91/attachment.htm