> > I don't much mind if we go up to 2.1 255 before 2.2.0... if we later don't
> > go past 2.2.4 ;-)
>
> 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?
How about letting the 'earley adopters' run 2.1?
I'de like to tell people: When it's even number I'de stake a weeks pay on
it being stable..
It's about consistency.
After 2.1 enters a freeze and has been there a few patches it should be
safe for most earley adoptors..
>
> 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
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu