[cgl_discussion] CGL and DCL trees
skip.ford at verizon.net
Wed Dec 11 15:21:45 PST 2002
Mika Kukkonen wrote:
> On ke, 2002-12-11 at 14:34, Skip Ford wrote:
> > It goes far beyond naming issues. They are handling the tree
> > incorrectly IMO. We already have enough trees that are staging points
> > for other patches to make it into mainline. The _real_ CGL tree (which
> > their's is _not_) should be a permanent tree which _rejects_ patches
> > that will make it into mainline. Those sorts of patches should go to
> > -ac or -mm or -wli or a dozen other come and go trees.
> > Somebody has to maintain all the patchsets that will _never_ be accepted
> > at least by Linus and the tree that houses those patches is the real CGL
> > tree, and that's not what the current "-cgl" tree is.
> No. The purpose of cgl tree is to keep some of patches that are not/did
> not make into current development kernel over into the next development
> kernel cycle. Like it seems now that George Anzinger's high-res timers
> is not going to make into 2.5/2.6, but we sure hope it will make into
> 2.7 or whatever is going to be the next one. If a patch gets ignored
> by Linus OR major distros over two development cycles, we will probably
> drop it and/or find some other patch to replace it.
What about the alternate timers patch? Why should a -cgl tree accept
George's patch over an alternate patch? The CGL Working Group doesn't
endorse any specific tree or code so competing patches should get equal
play in a tree named '-cgl.'
[I'm not bashing anyone's code here, just trying to understand. I don't
have any preference over either patch, and don't even know if they offer
all of the same features.]
> To say it more clearly, OSDL is _not_ in business of maintaining
> software (patches, whatever) _forever_, we are in business of "guiding"
> kernel development into the direction we feel it needs to go to fulfill
> the needs of our sponsors. And one (of many) way we do it is by giving
> patches like George's exposure in this cgl kernel tree.
So your -cgl tree is a temporary tree then.
> If there is some patch that will _never_ get into Linus'es tree, the
> distros will pick it up and maintain it, if there are clients that want
> to pay for that. Otherwise it will die, and that is called evolution,
> and that is A Good Thing (tm).
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
> 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.
More information about the cgl_discussion