2.6.36/37 suggestion
in [Kernel]
|
Prev: perf: rename common fields/functions from kprobe to probe.
Next: patch "Staging: ti-st: update ABI and TODO" added to staging-next tree
From: Oleksandr Natalenko on 29 Jul 2010 10:30 In reply to Ted Tso (http://article.gmane.org/gmane.linux.kernel/1008643) I would like to suggest kernel developers (first of all, Linus) some kind of compromise. Let's prohibit accepting new features during 2.6.36 merge window and accept only bugfixes until bugzilla and regression lists are empty. For drivers subsystem you may create separate branch and accept all changes there, then merge them into 2.6.37. It should resolve "features vs stability" problem for now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Theodore Tso on 29 Jul 2010 11:00
On Jul 29, 2010, at 10:25 AM, Oleksandr Natalenko wrote: > In reply to Ted Tso > (http://article.gmane.org/gmane.linux.kernel/1008643) I would like to > suggest kernel developers (first of all, Linus) some kind of > compromise. Let's prohibit accepting new features during 2.6.36 merge > window and accept only bugfixes until bugzilla and regression lists > are empty. For drivers subsystem you may create separate branch and > accept all changes there, then merge them into 2.6.37. Been there, tried that, it doesn't work. What people keep forgetting is that most developers are volunteers, and/or paid employees of companies that are primarily interested in well, doing development. So prohibiting new features doesn't help, because people will just keep coding them in their own branches, and then when when we do try to merge the new features, the resulting kernel becomes even more unstable. We have done graphs of the list of regression fixes over time, and after three months or so, the number of fixes that come in slow dramatically. So we could extend the waiting period by an extra month, say, and it might fix a few more bugs, but the result is that all of the various subsystem branches have even more development, which increases the instability during the next merge window. So this is a definitely a case of diminishing returns, and given the current set of developers, that's really all that can be done with what we have. Now, if someone wants to pay developers (the golden rule: he with the gold makes the rules) to work on nothing but trying to get accurate reproduction information from users, and then fixing the bugs for those users, then we can improve the number of bugs that get fixed. Or, if users with bugs want to get much more involved with testing kernels earlier in the -rc cycle, where it is easier to do git bisections, and to work harder to help the developers find and fix the bugs, then great, we can solve the problem. Or they can use a six-month-old kernel from one of the community distributions. Or they can pay for support from an enterprise distribution. The last two involve fewer features but hey, you just said you were willing to prohibit new features from entering mainline. If you want to deny new features to yourself, you're free to use a community or enterprise kernel. But trying to deny those new features to everybody else, including those who have no problems with the current system, does seem to be a bit arrogant, don't you think? So users have plenty of options. But trust me, trying to forbid new features in mainline is ultimately self-defeating. -- Ted (who still has his Lenovo T400 laptop running 2.6.35-rc3, mainly because it works for him and he hasn't had time to upgrade it to something newer) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |