On Wed, 20 Sep 2006, Andrew Morton wrote:
>
> Why would a shorter cycle be better? What are we trying to achieve?
I don't think a shorter cycle is necessarily better, but I think we could
try having a more "directed" cycle, and perhaps merge certain specific
things rather than everything.
That would possibly _cause_ a shorter cycle, if only because the problems
are hopefully more focused from the fact that we merged with a certain
focus.
Of course, it would likely just frustrate the people who didn't get
merged, and would need to wait for the next cycle. So it might be a net
negative, even if we'd bring individual cycles in a bit.
> > The cycles seem to be stretching out again, and I don't really think
> > it's worth it to hold up the entire kernel for every single piddly
> > little regression to get fixed. We'll _never_ be perfect, even if we
> > weren't slackers.
I think that's true. 2.6.18 got delayed partly due to me beign away, but I
also think that it then got delayed too much afterwards too, just because
I felt a bit nervous about having been away ;)
So it definitely stretched out too much.
Whether there is a lot we can do about it, I dunno. In many ways, the real
issue is simply that we have a lot of changes. And people are _never_ as
interested in the testing part as they were in writing new code..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
