The state of Linus

The kernel development process is going well, with one big exception, Torvalds said: developers still seem unable to distinguish the merge window from the period after -rc1 is released and he doesn't understand why. An extreme example was the MIPS subsystem which, as a result, was not merged at all for two release cycles. Most of the issues are not so extreme, but the problem is ongoing.

It is not, he said, that he will not pull new stuff into a -rc release — that actually happens fairly often. But, any maintainer who sends a pull request that contains work that is not an obvious fix outside of the merge window should include a long explanation. It should say why the pull request is happening now rather than during the next merge window, and it needs to include a description of the code that is being pushed. That description is often missing, he said, but it's important. During the merge window, he tends not to look at the code much, but that changes during the rest of the development cycle. Ben Herrenschmidt then joked that anybody wanting to sneak code in past Torvalds should be sure to send it during the merge window.

Torvalds went on to say that he does, in fact, look more closely at the code in some subsystems, even during the merge window. He is currently unhappy with the security subsystem, for example, so it gets extra scrutiny. What developers want is for him to be so happy with them that he never feels the need to look that closely at the code they send. "Then you can do anything".

When asked whether he would rather see a pull-request explanation in the emailed request or in the message stored with the tag in Git, he replied that, while the tag message is a little easier for him to deal with, it doesn't matter that much. What's more important, though, is that he gets a "human explanation"; he doesn't like explanations that just list the patches that are included. Maintainers who have other maintainers below them should also require good explanations and feed them upward. Torvalds wants the kernel to have good commit messages in general, and that applies to merge messages as well. If, for example, a developer is using bisection to find a bug and ends up at a merge commit, they will want to know what changes the merge brought with it.

On the whole, though, things are working well, he said; there are no huge problems. When asked about group maintainership at the top level, he said that he is open to the idea, but doesn't think that there is a lot of need for it. He manages to be responsive, even when he's off diving in some remote part of the world.

When asked about the use of signed tags for pull requests, he replied that he requires them for requests from trees that reside outside of kernel.org. But even for kernel.org trees, he doesn't necessarily trust the DNS server that points him there, so signed tags are still useful. That was your editor's cue to mention this article showing where signed tags are (and are not) in use. Kees Cook asked for permission to occasionally break his signature to test the system; Torvalds said that would be OK, but that those tests already happen routinely since James Bottomley uses keys with a three-month expiration. He did point out that he does not normally fetch keys, though, and so will not notice a key revocation. If a maintainer has to revoke a key, Torvalds needs to be told about it directly. Ted Ts'o suggested that any developer who generated a key on a Yubico device should check that key to be sure that it is secure.

Referring back to the LWN article, Ts'o noted that the map of pull requests is quite flat, and that most requests go straight to Torvalds. Might that lead to bandwidth problems at the top of the hierarchy? Torvalds replied that he didn't see a problem there; he would rather get five pull requests than one, as that makes it easier for him to verify things. Pulls generally take almost no time unless there are conflicts. He does do a build after every pull, which can slow things down a bit.

Stephen Rothwell, the maintainer of linux-next, asked if he should be verifying tags on trees pulled there. Torvalds replied that, while linux-next is wonderful for build coverage, almost nobody actually runs kernels from there, so checking the tags is less important. The value of linux-next is that it encourages maintainers to keep their code out in public and shows that the contents of a pull request aren't just something that somebody came up with the night before. It would be nice if there were more testing of linux-next, though. Almost every release, his wireless networking and graphics break, and he's not happy with that. Chris Mason said that he does get bug reports from people running linux-next, but it only happens a few times each year.

Rothwell let it be known that he gets irritated by trees that are rebased after -rc3 or so. Some trees, he said, seem to do that automatically, but it's not something that should happen without a good reason. Arnd Bergmann said that it's common for trees to rebase on top of a late -rc to pull in their own fixes that went straight to the mainline. But the better solution there would be to merge the fixes branch directly.

Rothwell said that he has recently been doing closer checking of the Signed-off-by tags on patches and has found a few problems where the tag doesn't match the committer of the patch. There are also cases where there is no signoff at all.

At the end of the session, Torvalds said that there was one other small problem he would like to see fixed. Many subsystems work in topic branches, but do no work in the repository's trunk branch. They merge those branches into the trunk and send the result up in a pull request. That means that the trunk branch doesn't have any work in it, and that tends to confuse him. It would be better, he said, to just merge the development branches together and send the result, leaving out the unused branch.

[Your editor would like to thank the Linux Foundation, LWN's travel sponsor, for supporting his travel to this event].