2.6 patch policy [LWN.net]

Anybody who has been following Linus's BitKeeper tree knows that very few patches have gone in recently. Linus is doing his best to restrict things to only the most important fixes. As a result, one might get the impression that 2.6 development has stalled. Development continues, of course, and bug fixes are being produced, but most of that work is not getting into the tree in the interests of getting a highly stable 2.6.0 release out.

Linus explains his policy this way:

I've been trying to be an absolute _bastard_ when it comes to patches. Yeah, I just looked. Lately they've been averaging about 3-4kB per day. And the sick thing is, I'm still not satisfied. I want it to become an absolute _trickle_ of one-liners that fix real bugs.

This policy makes some sense; it should quiet the waters enough to help the developers find most of the final serious problems in 2.6.0. The only problem, though, is that there is an increasingly large pile of patches which will have to go in after 2.6.0. As a way of thinking about what happens then, consider what Linus said almost three years ago, when 2.4.0 came out:

The linux kernel has had an interesting release pattern: usually the .0 release was actually fairly good (there's almost always _something_ stupid, but on the whole not really horrible). And every single time so far, .1 has been worse. It usually takes until something like .5 until it has caught up and surpassed the stability of .0 again.

Why? Because there are a lot of pent-up patches waiting for inclusion, that didn't get through the "we need to get a release out, that patch can wait" filter. So early on in the stable tree, some of those patches make it. And it turns out to be a bad idea.

To an extent, things have to be opened up a bit after the 2.6.0 release. The wider testing that the "dot-zero" release gets is certain to turn up new bugs that will need fixing. And a number of the fixes out there do need to go in before 2.6 can be deployed in a lot of production situations. So chances are good that the usual pattern will be followed; things will destabilize a little before 2.6 is truly ready for wider use. That, perhaps, is simply the way kernels have to be made.

(Log in to post comments)

2.6.0-test9 user

Posted Nov 20, 2003 11:54 UTC (Thu) by keithw (subscriber, #3127) [Link]

This makes a lot of sense to me - and the evidence from previous releases backs it up. Why should development restart again even in a limited fashion after the first (.0) release? Why not do development in a development branch, and possibly backport stuff to the stable branch later on?

The argument has been that there was a desire to have developers concentrate on the stable branch for a while prior to getting caught up in the new development branch - but it seems that the effect of this "concentration" is to reduce stability.

If 2.6 goes straight into a stability-oriented regime, and 2.7 kicks off immediately, it might even bring down the time to 2.8 (well, maybe not...)

2.6.0-test9 user

Posted Nov 20, 2003 15:48 UTC (Thu) by zander76 (subscriber, #6889) [Link]

Hello

Gererally I dislike the idea of starting a new branch straight away and there are a few reasons for this.

1. Its more fun to work on new stuff but the bugs really should be fixed.

2. Gives people a break, its not so much that people want a break but its a good idea to have one. You get a chance to really look at the current implementation and see people responces to it over a long period of time.

3. Gives all the maintainers a bit of a break, they still have to take in bug fixes but not as many when you compair it with taking in bug fixes and new features.

4. Gives everybody a bit of a planning state, people will start talking about new ideas and hash them out, but they aren't going in anytime soon so they can really give it some time and though. Usually there is some form of a conference were hackers can get together and work out ideas for the next release.

You have to keep in mind that most of the patches that are waiting are bug fixes and minor changes. The problem with these is they have a chance to introduce new bugs. They will have to go in, but if he starts putting them in now then we will never see a new version. So yes its true that after the new release things will become less stable because they will start allowing bug fixes in again, partly due to the backlog of patches and partly due to the fact that a lot more people are using it and they are finding more problems.

So yes it does seem like the kernel becomes less stable for the first few kernels but taking the developers away from it is not the correct solution. Having a 2.6.0 kernel that is stable is a completely different thing then having a stable kernel that works for everybody. 2.6.0 will be stable for people with specific machines and configs (to some degree) but 2.6.5 will be quite stable for everybody. To me that is the only way this could work.

Ben

2.6.0-test9 user

Posted Dec 2, 2003 2:28 UTC (Tue) by leonbrooks (guest, #1494) [Link]

So what you're saying, in essence, is...

it focusses people on fixing bugs
it gives people a break
it gives people a break
it gives people a break

I find Ross's argument more convincing (which see below).

2.6.0-test9 user

Posted Nov 20, 2003 19:51 UTC (Thu) by Ross (subscriber, #4065) [Link]

The problem with opening a new dev branch right away is that
the stable and development kernels will diverge. This means
that fixes in the development branch might not make it into
the stable branch and vice versa. This happened in 2.4. In
fact there are fixes in 2.4 which are still not in 2.6.0-test
because of that.

2.6.0-test9 user

Posted Dec 2, 2003 2:34 UTC (Tue) by leonbrooks (guest, #1494) [Link]

You have to balance that against the fixes which didn't happen anywhere because the developers didn't bother retrying when they were rejected during the prerelease bottleneck, and against the patches which hit the kernel hard because they developed in isolation and arrived in big chunks when contribution was opened up again instead of developing in manageable nibbles over time.

Also, I'm guessing that there are enough people working on the kernel now, and enough bodies practiced at kernel lieutenancy that we can well afford to open 2.7 the instant a 2.6.0-test1 is released.

2.6.0-test9 user

Posted Nov 20, 2003 18:00 UTC (Thu) by flewellyn (subscriber, #5047) [Link]

I'm hardly a kernel developer, but I quite like this idea, myself. Consider: as soon as Linus orders a "stabilization freeze", then 2.7 forks off. Initially, 2.7 and 2.6 are the same tree. Changes which help 2.7 can be easily backported to 2.6 later in the stable tree's development cycle, but in the meantime 2.6 has some real stability, and patches aren't being dropped.

This way, everybody wins. Patches are going into a tree and getting testing, development continues, and the stable tree has a chance to crystalize.