Starting the 5.0 charter process

[glenn.seiler@xxxxxxxxxxxxx (Seiler, Glenn)]

We need to start this process that we agreed to back in June at the LF
LinuxSummit.

To that end I'll start by putting some concepts out for discussion
before starting a draft of the charter.

The first and most important thing that strikes me about the new charter
we [loosely] agreed to in June is that it is a very fundamental shift
from the original charter. To be more clear; the original charter was to
define characteristics of a Carrier Grade system - some existing, some
not - that must be present in order for a system to be defined as
Carrier Grade. These requirements came directly from NEPS and Telecom
platform providers - those most knowledgeable to provide such
requirements. The result was a blueprint that distro's could map against
and NEPs could use as a sort of metric. 

If we move to charter to essentially specify gaps - things not in the
current Linux kernel and associated packages - then the document, or
spec, or whatever it becomes, cannot really be used to define
capabilities of an OS, because by definition, the requirements do not
exist. Ok, so maybe a distro may have a few of the 'non-existing' gaps,
but for the most part it becomes a document that no one can really map
against. 

So the charter changes significantly; rather than a document that
defines the characteristics of a CG system, it now becomes a "message to
the industry of what Telcos need and isn't available". A wish list. My
fundamental question is "what value to the NEPs is a wish list"? Perhaps
great value. But I am not the right person to answer that question. Now
if the community reacts - either through LF, through distros and
platform providers, or through grass-roots projects, then this document
can become of great value. But if the community does not react, it
becomes a nice exercise. 

The concept of registration, or certification, or LSB module essentially
goes away. How do you certify or register against things that do not
exist yet? I suspect that will make some very happy, but I think it is a
great shame. 

So, with my preamble out of the way, and a basic question asked of the
key consumers of this document, here are some ideas for moving forward.

1) we should create the document similar to an RFP. The RFP should come
from LF. It should be an RFP for CG requirements not met today. This
process would give equal opportunity to everyone; SCOPE Alliance,
individuals in the community, distros and platform providers all would
equal opportunity to submit requirements.

2) Just like an RFP, there should be a timeframe for responding.

3) There should be a "maintainer" of the requirements that resolves
conflicting requirements, overlaps and redundancies. Without a
'maintainer' the process would quickly become chaos.

4) The maintainer should be a neutral party, (..LF). If not, some
democratic process should be created to determine a maintainer.

5) There should be a template that 'suggests' the way requirements
should be submitted. Nothing too rigid. The template should come from
LF, with input from this list of course.

6) As we discussed in June, the requirements should be "What" of
requirements that do not exist today. Not the "how". 

7) I'm not sure this process or document should be restricted to the
kernel proper. I suspect there are valid requirements in user space as
well. 

---------------------

Ok, that is all I can think of now. I'm quite sure I am missing
something and of course, this is an open process so I expect a lot
comments. 

Regards,

-glenn

 
Glenn Seiler, General Manager Linux Solutions, Wind River
direct +1.510.749.2122  mobile +1.831.334.4108
fax +1.510.749.2695
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lf_carrier/attachments/20070816/b71758e7/attachment.htm