Kernel Summit 2007 - an advance view
Posted Aug 26, 2007 17:22 UTC (Sun) by mingo
In reply to: Kernel Summit 2007 - an advance view
Parent article: Kernel Summit 2007 - an advance view
I don't think slowing down is a good idea. It would just make things languish in git trees for a little longer but it wouldn't result in many fixed bugs.
Yeah - or worse, it would force developers to go elsewhere.
I think the right approach to high-flux development is three-fold:
1) decrease the latency of getting the latest kernel to the user. 2-3 months release cycle pushes human limits but is doable. 2-3 _days_ is doable latency for the -git kernel, for bleeding-edge testers: today a fully packaged up rpm kernel of latest -git is yum-upgradable 1-2 days after Linus commits a change into his tree.
2) increase the likelyhood of users to report back a bug and for them to test fixes. This one has many aspects: good debugging infrastructure (many automated debugging features, automatic bisectability), meaningful (and early enough) debug output, and rewards to testers who report back, responsive maintainers, etc. This is where we have the biggest technical deficiencies right now.
3) maintainers must push back on unrobust code, as a function of how stable the _previous_ release was. If the previous release was too unstable, be stricter in the next release. If the previous release was too boring, risk more changes. 2-3 months of a delay to a feature is not the end of the world - with a release cycle longer than that it can be lethal to motivation.
The biggest problem is the fundamental lability of this dynamic system: if the kernel gets buggier then users go away, due to that the kernel gets _even more_ buggier (and kernel developers wont even notice initially), then developers go away too, etc. It quickly spirals out of control and detaches the kernel developer community from the user community. That is what happened with Linux 2.5 and it took years to fix up and get Linux 2.6.0 out of the door.
Sticking to the "90 days max" release cycle is key. That is what keeps us all honest. If we mess up then the only true recourse is to release a buggier kernel, and the punishment for that is much more direct (and unpleasant to the kernel developer) "your kernel is buggy" (or "your subsystem is buggy") impression than a "slip in the release date" action is - so it's a far more efficient method of feeding back the true quality of the kernel back to the developer community and thus keeping the quality of the kernel up high enough.
to post comments)