> > >
> > > One of the ways in which the 2.3 cycle can be shorter is
> > > by only integrating stuff that's already being worked on
> > > and is ready by the time 2.3.0 is forked off. Then we
> > > integrate all those things within 5 revisions and start
> > > debugging. Maybe we even want to distribute all of those
> > > things in one big patch _before_ 2.3.0 is forked off.
>
> I think rolling it all into one large patch would be a bad thing, who's
> going to oversee integration? Linus. woudl you want to stare at upwards
> of 1 megs of diffs spread across 5 revisions?
Nope, that would be torture for Linus... At least unless they were neatly
explained and separated into categories & non-interdependant.
> I think if anything like that was done, only dependant features should be
> rolled. if something doesn't depend on anotehr fetaure, it should remain
> a sole feature for Linus to look over (or whoever would be maintainer)
I believe that the most important thing for a such list would be to debate
the future of the kernel and its features, NOT to bounce patches/code.
Until we have actually come up with nice concepts, it's too early to
implement anyway. And I think that Linus need to participate to stop the
meaningless ideas. After all, if the ideas doesn't pass Linus, it won't
get into the kernel in the first place anyway...
/David
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/