KS2011: Development process issues

The closing slot in the first day of the 2011 Kernel Summit was dedicated the traditional session where Linus Torvalds and Andrew Morton talk about the development process and how things can be improved. There were not large numbers of complaints to be heard this time around.

Linus started by saying that he is happy; there is no subsystem that he wants to slam this year. In his mind, the biggest problem we have is the increase in kernel complexity. We have, he said, been adding new features and clever code too aggressively. The memory management subsystem stands out, but he is confident that it is happening throughout the kernel. But, at least, he does not see any serious process issues like we have had in previous years. There are no big conflicts, and his laptop hasn't broken in a while.

Maintainers, he said, should say "no" more often. Once upon a time it was Linus's job to do that, but he really can't enforce it anymore. The number of patches that he merges directly is quite small; that leaves him with the option of taking what he has been given or rejecting an entire pull request from a subsystem maintainer. It's those maintainers who have to take on the "say no" responsibility now. There does not need to be any specific reason to turn down a patch, he said; what is really needed is a reason to accept a patch.

Dave Airlie complained about the number of patches that break the kernel and make bisection of problems during the merge window impossible. Linus acknowledges the problem, saying that he wishes every tree that feeds into the kernel would be bisectable, but that is never going to happen. There was some talk of fixing up git so that bisection would stop between merges into the mainline (instead of in the middle of them) when possible. Trees are usually more stable when they are pushed to Linus, so that approach should make bisection a bit more reliable. That is especially important for problem reporters who are not kernel developers and who cannot be expected to cope with kernels that explode in the middle of a bisection series.

Going back to saying "no," Ingo said that it can often be hard to make a "no" stick. Sometimes, a developer of a rejected patch will rewrite it to make it applicable to a different subsystem, then merge it through a more agreeable maintainer. He would like a tag ("Rejected-by" or some such) that developers would have to apply to patches after they had been turned down by one subsystem. Linus made the reasonable observation that developers might show a certain lack of diligence when it came to adding those tags, and that the exercise wasn't worth the effort. No system is perfect, he said, and we shouldn't aim for perfection in our processes.

Arnd Bergmann asked if we were reaching a point where there is support for too many architectures in the kernel. There are two more poised for the 3.2 merge window, and at least four in the works thereafter. Linus said that architectures are sort of like filesystems; we have a lot of them but few of them are heavily used. The cost of the other architectures is not high, though; the quality of the code has been fairly good and they do not add complexity in general.

Dave Airlie asked about the idea of merging more user-space code into the kernel. Linus said that he is not against it; it has been good for projects like perf. Sometimes people try to take it too far, but that is normal; it's a balancing act like any other. He is not convinced about QEMU, which is an idea that has been floated a few times.

And that is where the first day of the 2011 Kernel Summit wound down, with several developers heard to be muttering about beer.

---

(Log in to post comments)