Is Linus happy?

It is traditional for kernel summits to close with a session about the development process as whole and, in particular, about any problems that Linus sees. The 2015 event was no exception here. The bottom line is that, while there are always things that can be improved, Linus is pretty happy with how things are working now.

He started by saying that, if the topic of the session was truly "is Linus happy?", the group could all just go home. He had no big issues to complain about. He did take a moment to whine that Dave Airlie tends not to use capitalization in his changelog entries, though.

Linus has one small wish that, he said, seems unlikely to ever happen: he still misses having a maintainer for the list of regressions. The process seems to work well enough without that, but it forces him to go by his gut feelings when deciding whether to delay a release or not. Perhaps it doesn't matter, but he would still prefer to have somebody tracking regressions.

The other thing he wanted to talk about is maintainer groups. Most subsystems are maintained by individuals, but, Linus said, the subsystems that are maintained by groups have worked out well. He would like to see more maintainer groups in the future. Having a group helps to maintain coverage when somebody is busy; it also makes it easier for a maintainer to depart when they want to move on to other things.

Maintainer groups would be especially helpful for certain areas where he has been getting complaints. He singled out the SCSI tree as one in desperate need of group maintainership. When a subsystem isn't working well, the complaints end up with him, and that makes him unhappy. The other area where he gets complaints is the virtual filesystem layer. Al Viro is great when he's around, but he tends to vanish. Finding a co-maintainer for Al is not an easy task, though.

Linus was asked whether he, too, should have a maintainer group. The short answer was that he didn't think it was necessary. He is happy to be there seven days a week, and doesn't have trouble taking time off when he wants to. Being the top-level maintainer is not a big stress for him. So he doesn't think a co-maintainer is needed, though he is happy to talk about it if others disagree. Christoph Hellwig suggested that it should happen eventually, but it is not one of the most urgent problems to solve now.

Tim Bird asked about the problem of unresponsive maintainers in low-level parts of the kernel. What can be done to get rid of a slow maintainer? Linus said that this issue has come up a number of times before; sometimes the maintainers eventually just go away. If that doesn't happen, the next step is to just start sending changes to Linus directly. He's not happy when that happens, but it is a workable fallback when the process is otherwise stuck.

Arnd Bergmann talked a bit about how the arm-soc maintainer group works. They (he and Olof Johannson) have a secret mailing list for patches and pull requests. Things pile up there, and sometimes a couple of weeks can go by where neither maintainer processes things. When somebody finds some time, they acquire the queue lock via a message on the IRC channel and crank through requests. They maintain about six branches that go to Linus, and one that feeds into linux-next.

When asked about testing, Arnd said that they do a lot of build testing of patches. Most of the regressions they encounter are not ARM-related, though. Additionally, Olof runs an automated build-and-boot system to test incoming patches.

Thomas Gleixner said that the management of the x86 tree is similar. They (Thomas, Ingo Molnar, and Peter Anvin) have a huge number of branches; people complain sometimes, but all the branches make life easier. The group has an agreement over who owns each branch at any given time. They, too, employ an IRC locking protocol. Ingo runs a continuous-testing setup.

One important practice for a successful maintainer group, it was agreed, was good communication between maintainers allowing them to present a consistent interface to developers.

Christoph complained a bit about the staging tree. He said that it breaks allmodconfig builds, but that problem was evidently fixed a while ago. He also dislikes the Lustre filesystem, which has been in staging for some time now; Greg agreed and said that he would like to delete it. It was generally agreed that the work being done on Lustre is not substantial enough to justify its continued presence. Christoph also said that the use of the staging tree for code that is about to be deleted could be improved; there are, he said, people doing white-space fixes on doomed code.

Linus highlighted one subsystem that always works well for him, despite its being the largest subsystem in the kernel: the networking tree. Dave Miller admitted to being a bit of a control freak who tries to do everything, but he also said that the networking patchwork system helps a lot. Dave doesn't mind sitting in patchwork and checking boxes all day. Linus jokingly took back his praise shortly thereafter, when he found a big pull request from Dave in his mailbox. The joking stopped after the summit was over when that request elicited a classic Linus rant that has been reproduced all over the net.

The final topic was tree-wide changes, which often prove to be disruptive. Linus's answer was to simply not do them; they are a huge pain for everybody. When they really cannot be avoided, though, there seems to be no "best way" to handle them. Thomas suggested doing them quickly and just getting the whole thing over with. Beyond that, though, there were not a whole lot of suggestions.

At that point the 2015 Kernel Summit broke up and the attendees went off in search of a well-earned beer.

Index entries for this article
Conference	Kernel Summit/2015

---

(Log in to post comments)