Maintainers Summit: SPDX, cross-subsystem development, and conclusion

SPDX tags

Greg Kroah-Hartman told the group that, of the approximately 60,000 files found in the kernel repository, some 11,000 have no license text at all. That can be a bit problematic, since the Developer Certificate of Origin that covers contributions to the kernel refers to "the open source license indicated in the file". To fix this problem, Kroah-Hartman has put together a series of patches adding one-line SPDX tags. He asked whether there would be an objection to a patch adding those tags to 11,000 files; none were raised. The first set of SPDX patches was subsequently pulled for 4.14-rc8.

Linus Torvalds said that he would eventually like to see SPDX tags on all 60,000 files in the kernel. There are people who want do automatic license tracking who would benefit from those tags. He's happy to add a single line to files with no license text at all to start with. For the files that do have license information, there are about 700 variants of the GPL text in the kernel, mostly varying in trivial ways (white space, or which address was used for the FSF office). SPDX offers a way to bring some uniformity to those license declarations. Adding tags to those files is a bigger job, though. While no-license-text files are implicitly GPLv2, files that contain license text must get a tag that matches what the text says. If the file is dual-licensed, for example, the SPDX tag must reflect that.

Might it be possible to get rid of all that license boilerplate and rely completely on the SPDX tags? That would be nice, Torvalds said, but that is not something that can be done in any sort of automatic way. Removing copyright information from files is fraught with all kinds of hazards and must be done carefully. So, for the short term, adding the tags to those 11,000 files with no text will have to do.

Kees Cook asked whether all new files added to the kernel should have SPDX lines; Torvalds answered in the affirmative. One remaining glitch is the files that define the user-space API; they will need to be annotated with a tag that includes the user-space GPL exception.

Cross-subsystem development

The kernel's maintainer model is normally quite effective at avoiding conflicts between developers; almost all work fits within a single subsystem. But, occasionally, a developer must make changes that affect a large set of subsystems; these changes can be hard to merge without creating a lot of conflicts. The best way to handle these changes has been a Kernel-Summit topic before, and it came up again here.

Cook, who has been pushing a wide-ranging set of timer API conversions, started off by saying that he often doesn't know how to direct such patches. It depends partly on whether they are API conversions or new features. The former are often best merged by him directly, while the latter often have prerequisites that complicate the picture and usually have to be merged though the relevant subsystem tree. He has tried to mark the two different types of patches in various ways, and still isn't clear on the best way to proceed. Among other things, that leads to ambiguity regarding whether he expects another maintainer to merge a specific patch or whether he wants an acknowledgment from that maintainer before merging the patch himself.

Developers who are generating large cross-subsystem patches should ensure that the relevant maintainers get a copy of the "0/N" message explaining the series as a whole. That often doesn't happen (git send-email tends to be the culprit here) leaving maintainers missing some important context.

Ted Ts'o mentioned the RichACL patches, which have been circulating for years and are now up to version 27. Much of the work in this series applies to the virtual filesystem (VFS) layer, so he doesn't think it's appropriate for him to review it; meanwhile, the parts that are specific to ext4 are irrelevant until the VFS piece has been reviewed. Arnd Bergmann said that he, too, has VFS patches (year-2038 fixes) that are needing review. Torvalds agreed that VFS can be a problem area when it comes to patches like this. There has been talk of adding a second VFS maintainer in the past, but that has gone nowhere. He would still like to solve that problem, but the community first needs to find a candidate to do the work.

Somebody asked about the status of the trivial tree, which traditionally has handled tiny patches and can be suitable for some cross-subsystem work. Jiri Kosina replied that he had suspended the maintenance of that tree due to lack of time, but it is back in operation now.

Cook noted that the path taken by patches to the mainline isn't always clear, and asked whether the maintainer hierarchy should be represented in the MAINTAINERS file. Torvalds replied that the information should already be there, but Cook said it's far from clear when the maintainer relationships don't match the kernel's directory hierarchy. Bergmann said that the arm-soc tree, which sits between system-on-chip maintainers and Torvalds, is deliberately omitted from the MAINTAINERS file. The arm-soc maintainers don't want to receive random email, and the maintainers who need to feed patches through arm-soc know where the maintainers are. But, he said, there would still be value in documenting this relationship somewhere.

Torvalds said that he gets annoyed by cleanup patches that have been split up excessively. He would rather see a single commit that just gets the job done; that makes merging easier.

The discussion concluded by going back to the timer changes. Cook said that perhaps he should have just sent the mechanical API changes after -rc1 came out. It was asserted that nobody would complain about such a merge — except that, perhaps, the maintainers of the graphics tree (none of whom were in the room) would.

Evaluating the Maintainers Summit

As lunch called, the participants at the summit briefly discussed the event itself. Torvalds said that he liked it, and that the size of the group (around 30 maintainers) was about right. Bottomley said that there were a number of Kernel-Summit sessions that would have benefited from Torvalds's presence; without him, they were unable to bring various discussions to a conclusion. The tracepoint ABI question was one such issue. Torvalds reported that he had talked with Steve Rostedt and come to a conclusion on how to proceed there; the details can be found in this article.

Next year, the Kernel and Maintainers Summits will be held alongside the Linux Plumbers Conference. There was some discussion about whether the Maintainers Summit should come first, or whether it should be held at the end, as it was in 2017. The conclusion was that holding the Maintainers Summit on the last day gives an opportunity to revisit issues that couldn't be resolved in the other sessions, so that is how things will be in 2018.

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