Some development model notes
The interesting thing with this discussion is that the people objecting to the current development mode have not been able to point to much in the way of specific problems that have resulted from it. A few specific bugs have been listed, but most of those have been around for some time and cannot be said to have resulted from recently-merged new features. The only complaint which holds water might be this one regarding the plight of some out-of-tree kernel development project (PaX in particular). PaX, it seems, is stuck at 2.6.7 because its developers have not yet been able to respond to subsequent changes in internal interfaces.
This argument, of course, does not get very far with most kernel developers. There is an increasing amount of pressure to get out-of-tree projects to submit their code and become part of the mainline tree. Code which is in the mainline gets fixed (usually) when internal interfaces change, but only the original developers can maintain external code. So the standard answer to this sort of complaint is "merge your patches." Changes in the development model to accommodate out-of-tree projects are unlikely.
Not every 2.6 kernel release has been 100% stable, but the same can be said of previous stable kernel series as well. What is different this time is that 2.6 has a great many new features and improvements which would not have been merged under the older model. Many of those improvements would, instead, have been backported by distributors and shipped as part of the "stable" kernel anyway. Under the new scheme, those patches are merged into the mainline, are debugged by everybody involved, and are available to all users. It seems unlikely that most users truly wish to go back to the old days, when distributors shipped highly divergent kernels with (literally) hundreds of patches.
There are occasional requests for bugfix-only "point" releases for the major 2.6 kernels. Rather than wait for 2.6.10, and take all of the other changes which come with that kernel, some people wish for a 2.6.9.1 (and so on) with just the important fixes. The standard response to that request is that anybody can create and maintain such a tree. So far, however, there has not been sufficient demand for this tree to motivate somebody to actually do the work. (It should be noted, though, that Alan Cox has restarted posting his "-ac" patches, which contain fixes that are, in his opinion, important).
All of the above distracts from the real development model discussion: what Linus should call his intermediate releases. There is a steady stream of objections to the "-rc" scheme, since, in fact, very few such kernels are actually release candidates. Linus pondered the issue, but decided to call the first 2.6.10 prepatch 2.6.10-rc1 anyway:
So the -rc names will continue for the foreseeable future.
| Index entries for this article | |
|---|---|
| Kernel | Development model |