That sounds like a very cathedralish thing to say. What is the problem
with having a few bugfix releases in the stable kernel?
Why not let the experimenters run free in 2.3.xx, the early adopters
shake things loose in 2.2.0-10 (or whatever it takes for about two
months to go by) and those people that have really critical
applications jump in around 2.2.11?
It seems like we have a pretty interesting optimzation problem going
on here.
1) To keep linux moving forward we want to maximize creativity and to
avoid the risk of huge diffs and overlapping modifications of code we
don't want to have feature freezes for very long.
2) We need feature freezes for long enough that all the different
sections of the kernel are tried out.
3) To keep linux stable, we want to maximize the number of people
working with it and therefore exposing bugs in it.
4) To keep linux's reputation we want to show the world that you make
things right the first time.
It seems to me that one way to accomplish these goals would be to make
three trees instead of two. A stable 2.0, a coming to convergence 2.2
beta followed by official 2.2's and a 2.3. Another way to approach it
would be to move to the next stable release shortly after the freeze
and let the kernel converge there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu