[cgl_discussion] CGL and DCL trees

[Steven Dake]

>
>
>But those distros need a place to return updates to.  Maybe I'm dreaming
>but if each of them is maintaining their own branches, the code will
>never be shared (in an organized way anyway.)
>
>I still think there is a need for a permanent cgl tree (or project) for
>vendors.
>
>  
>
This doesn't make alot of sense to me.  There are several reasons that 
vendors will not be interested in a permanent cgl tree.  Specifics 
include their own patches, ensure that patches meet their own quality 
criteria, and extend the linux kernel in many ways.

A good example is support for alternate architectures such as Xscale/SA. 
 The default linux kernel doesn't support XScale.  Does that mean the 
CGL tree becomes a complete integration of other non-IA platforms?  I 
don't think the cgl tree maintainers would want to become a linux vendor 
and do all the nasty work of integrating several architectures and 
several features.  If they wanted to do that, they would get out of the 
OSDL business and get into the OS business.  This is why I don't 
understand why OSDL would bother maintaining any tree at all, but hey 
its a free country.

Vendors don't need an extra tree to deal with.  At MontaVista, we 
already have over 30 trees (features, architecture support, patches) 
that must be integrated.  We definately don't need an integrated tree to 
try to pull apart to reintegrate into our already integrated tree.  I 
think you will find most Linux vendors in agreement here.  Linux vendors 
want to ship their own tree; its a percentage of what defines their 
value add.

For MontaVista's latest carrier grade edition product, we used the CGLE 
integrated tree and I personally found it to be very painful and reduce 
the level of quality we could apply to our product.  Now we were taking 
unaudited code from many unknown sources.  It makes more sense to take 
audited code from known sources and if quality is suspect, apply code 
review to the incoming code to ensure it meets quality standards.

Now if you want to bother maintaining an integrated tree for the few 
people that might be interested in taking a look at the OSDL features 
that is fine.  But these folks shouldn't have any issues integrating the 
features they are interested in themselves.  If they do, they probably 
are not capable of using/understanding/commenting on the features in the 
integrated tree anyway.  And really, how many people would be interested 
in such a tree?  Less then 5 ?  Is it really worth the effort?  Only 
customers are interested in an integrated tree.  I don't see Joe running 
CGL tree on his desktop anytime soon.

Thanks
-steve

>>We are not a standardisation body like POSIX, that accrues err... cruft
>>(?) over the time. We are able and should drop things if they do not
>>look viable.
>>    
>>
>
>  
>