Linus Torvalds wrote
>So I could throw a 2.6 directly over the fence, and start a 2.7 series,
>but that would have two really killer problems
>
> (a) I really don't like giving something bad to whoever gets to be
> maintainer of the stable kernel. It just doesn't work that way:
> whoever would be willing to maintain such a stable kernel would be a
> real sucker and a glutton for punishment.
.
.
>The _real_ solution is to make fewer fundamental changes between stable
>kernels, and that's a real solution that I expect to become more and more
>realistic as the kernel stabilizes. I already expect 2.5 to have a _lot_
>less fundamental changes than the 2.3.x tree ever had - the SMP
>scaliability efforts and page-cachification between 2.2.x and 2.4.x is
>really quite a big change.
I think theres a more fundamental problem with our model of kernel
development.
It would be nice to have stable kernel releases much more often, say
every 6- 8 months.
Or at worst once a year.
But the way we do development just doesn't lend itself to that.
Lots of experimental code gets dumped into the devel kernel, by the time
that gets sorted out, something else experimental has been pushed in
elsewhere. We try to get around this by having freeze periods, but that
seems unnatural. And in a freeze period, you have the quandry of if
something is unstable, do you try to fix it or do you pull it out.
Essentially the problem of stabilising a devel kernel is itself
unstable. Its a battle between bug fixers trying to stabilise things and
developers trying to get new features in. And to go from a devel kernel
to a stable kernel, everything has to be stable at the same time. Which
historically has been a real problem :-)
I don't know if it would really work any better in practise, but I would
like to propose for consideration a 3 level model of kernel development.
You have 3 kernel trees
2.4.x: the stable kernel
2.5.x: the development area for our 2.6 candidate
Experimental: the real development area
The basic model of development is that code gets developed and tested in
experimental.
The only thing stuff that gets into 2.5 is code that has been in
experimental for a while and generally considered stable.
The goal is that at any point in time, 2.5 should be a fairly reasonable
candidate for 2.6.
Every so often when there's general agreement, 2.5 gets promoted to 2.6
and we start again
We don't have the great quandry of how to stabilise 2.5 enough to be
ready for a stable kernel. Its always more or less ready. So we can have
a much quicker cycle time.
The only stuff what would go into 2.4 is clear bug fixes and
occasionally stable code (eg drivers) from 2.5 which have been
backported.
People have been sort of using this kind of scheme unofficially anyway.
Alan's AC kernels and Andrea's AA kernels have been sort of fulfulling
this role. I am suggesting that we formalise this arrangement.
--
Robert Cohen
Unix Support
TLTSU
Australian National University
Ph: 612 58389