WARNINGS / DISCLAIMERS:
* Although this is a topic that could start a flamewar, please don't.
* If this has already been discussed before (i.e., in _recent_, _applicable_ history), just point me there and be done with it.
* I'm a relative newbie to Linux (only ~ 2 years)
My issue is with the length of time between stable kernel releases. Take USB for example. 2.3.x had a relatively stable USB implementation for a while, but other messes prevented USB support from going into a stable kernel for how long? Two years after Windows 98 had support?
My proposal is to shorten the open development time a lot. Feature freeze after maybe 2 months, not 2 years (exact numbers are disputable, but on that order of magnitude). During the next month or month and a half, extensive testing, and no new features, period. The big patches will keep coming nevertheless (e.g., the big VM patch and the stat() changes as discussed earlier), but they should not even be considered to merge into the frozen kernel. Then, during the open development time for the next devel kernel, all these patches can be integrated and fought over. But stop fighting over it after the freeze.
I know for sure that a lot of the kernel developers will not like working this way. I can anticipate the flames already: not enough time to debug stuff, not enough time to consider the merits of patches, too much rush to release that bugs might remain, and others.
I think that there will be enough time to debug new features. With a short open development time, there will be less radical changes, and a smaller group of features that could have problems. Also, the kernel goes through several patchlevels in the stable tree before distributions start including it. Because of this, the 2.<even>.0 release could still have a few bugs, just not the showstoppers. Many more people will start to use the new stable kernel, find some more bugs, and maybe even submit patches. But production systems will wait, as always, for the 2.<even>.6 or higher, as will the distros. Yes, a lot of this is how the kernel development should work in theory.
The merits of patches can be flamed over during the freeze, giving plenty of time to discuss stuff while preventing the premature patches from being merged anyway and thus extending the development time. And besides, a good flamewar should not need months to resolve. _Should_.
There will not be a rush to release so great that major bugs could leak through. Remember, it always takes longer than expected. If we say that the freeze will last two months, it will in fact last at least six months. But the key is to enforce the fact that the kernel is frozen during this time.
To the other naysayers, why don't we try this (at least the key part -- short open development time) for one kernel release. If everything totally fails, the worst that could happen is that we are left with a sub-decent development kernel that already has the big patches merged.
Comments? Suggestions? Cold fire?
Kenneth
Feel free to ignore me.
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
-
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/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:19 EST