Carrier Grade Linux/Gaps Alpha1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Greg,

On Tue, 2008-05-27 at 08:40 -0700, Greg KH wrote:

> On Tue, May 27, 2008 at 08:19:05AM -0600, Troy Heber wrote:



> > > Why is it a requirement?
> > 
> > Because it was submitted to the CGL working group as requirement by a
> > contributor who would like to see the feature implemented in the Linux
> > kernel. It was evaluated by the working group, accepted, given an
> > appropriate priority, and finally placed in the gaps documented.
> 
> {sigh}
> 
> I thought you all were moving away from the "accept a random feature
> requriement" to the more useful "accept a problem that needs to be
> solved" type model.

We actually have a formal process for accepting new gaps from SCOPE that
involves nearly no 'accept random feature' steps.

Seriously, though, that process is formalized and structured in a way
that will (hopefully) allow for a maximum amount of communication and
review of any new requirements coming from that direction.

As for accepting requirements from other sources, the process there is
what we're going through now, bring it up on the mailing list or in one
of the CGL Workgroup meetings.  In our last meeting we agreed that we
were going to have a web page created for submitting requirements for
review and then we would have an open discussion of them prior to them
ever being formalized.  I don't know if we have that page up yet, but
it's in the near future if it's not here today.

You need to remember,  though, that what we're talking about here isn't
a new requirement, it's one that has been around for a while and we
haven't finished reviewing all of them yet.  I'm happy to have this
discussion but as Troy said, this requirement was important to someone
who submitted it to the group and at the time it was accepted as valid.
The process now is to look at the requirement, determine if it is still
valid or relevant and if not, deprecate it.

This is, as far as I know, one of the correct places to have that
discussion, by the way.


> > > What is supposed to happen if this is implemented?
> > 
> > In a perfect world the implementation would be flawless resulting in
> > faster boot times.
> 
> Are you sure that this is an area in which the boot time of Linux is
> slow?  By what ratio in comparison to other areas?

You'd said you implemented and removed it, so multiple someones were
sure enough about it to get it accepted at one point.  What was the
motivation for removing it?  If it's already been tried and shown to not
work, that's a very compelling argument for deprecating the requirement,
or at least re-opening the discussion on the validity.  Do you have
benchmarks that you can share?

In that same vein, the way we're going to get better requirements is to
have more active participation in the evaluation process as the
requirements are submitted to the CGL workgroup.  And we're always
looking for active members.  *hint, hint*


Joe MacDonald, Member of Technical Staff, Wind River
direct 613.270.5750  mobile 613.291.7421  fax 613.592.2283   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lf_carrier/attachments/20080527/53c5c187/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.linux-foundation.org/pipermail/lf_carrier/attachments/20080527/53c5c187/attachment.pgp 


[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]     [Asterisk PBX]

  Powered by Linux