Messages in this thread | | | Date | Thu, 13 Jul 2000 14:18:56 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [Announce] BKL shifting into drivers and filesystems - beware |
| |
On Thu, 13 Jul 2000, Richard Gooch wrote: > > Perhaps the solution is to have shorter development cycles. Say 6 > months before feature freeze, then a planned 3 month shakedown > (extended only if there are reliability problems). Part of the problem > is that so many new things get piled into each development series. Cut > back on the number of significant things per cycle (say just one or > two).
I agree.
This was what I wanted for the 2.2 -> 2.4 change too, and a much shorter development cycle would be wonderful. It obviously was not to be: 2.4 is already about 18 months out. We're not as bad as the 2.0 -> 2.2 cycle was, but it's painful.
It seems to be a lot harder than it should be to keep short development releases. I certainly haven't found the magic combination yet. 2.4.x is definitely all I hoped for (the big goal for me was to make sure that the mindcraft-like web-performance scalability problems would be gone, and we definitely fixed that), but it took much too long.
What would help would be more modular releases: smaller pieces of the kernel getting released independently, allowing for smaller and shorter release cycles. In Linux at least we don't have the "whole world" release issue that most other OS people have (including the free ones: I think the BSD "world" approach is horrible partly because of the release issues), but even just the kernel is so big that it would be nice to be able to see it as multiple independent projects.
At the same time it's obviously not true that there are independent projects, and especially drivers (which _sound_ independent) are very likely to be impacted quite a lot by infrastructure changes. There are no really clear lines to split development up by, and the cures are worse than the disease ("microkernels", I hear somebody shout. But that approach would just make it impossible to do the kinds of improvements we _have_ done and probably will continue to do).
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |