Is the kernel development process broken?
Posted Mar 9, 2005 22:28 UTC (Wed) by iabervon
In reply to: Is the kernel development process broken?
Parent article: Is the kernel development process broken?
The problem with that idea is that the "fix it up until it's stable" step actually properly involves sitting for three months waiting for bug reports to come in and otherwise doing nothing at all. The average bugfix involves one developer writing two emails a day for a week to whoever reported the bug trying to work out what's going on, and there are maybe a dozen such bugs outstanding at a time. That's maybe 120 manhours/week out of the 16000 available. Kernel developers seem to be unwilling to spend half of their time waiting, and users are willing to wait until it's too late to report bugs anyway.
The reality is that developers will continue to work on their projects at all times, because that's what they are paid by their employers to do. The mainline has to pick up this work at some point, or it eventually becomes irrelevant. A kernel version cannot begin to stabilize until it gets a mainline release.
The changes which were needed to the process are exclusively that developer priority has to be given to fixing bugs as soon as they are reported, and those fixes have to be released in a version that doesn't have any other changes that haven't seen widespread testing in the real world. It doesn't matter to stability what the developers are doing during the 99% of the bugfixing period that doesn't actually involve any work on fixing bugs; what matters is the the results of bugfixing actually get applied to the kernel with the bugs in such a way that the process converges to a series of kernels with 0 bugs instead of to a series of kernels with a small constant number of bugs. There is a huge difference to users if each minor release creates a few new bugs and then fixes them in a few patch releases versus each minor release fixing a few bugs and creating a few new ones.
to post comments)