On the problem of maintainer abuse [LWN.net]

By Jonathan Corbet
December 17, 2014

As can be seen in the LWN kernel patch tracker (or in the patches section of the weekly Kernel Page), there have been a lot of significant patch sets posted over the course of the last week or so. The pace of kernel development continues to increase, so there is always a lot of new code out there in need of review. There's just one little potential problem: as of this writing, the 3.19 merge window is open, and many subsystem maintainers are busy getting the current set of changes into the mainline and dealing with any resulting fallout. They are unlikely to have much spare time for patch review.

Merge-window patch postings are not uncommon; most maintainers either just defer looking at them or ignore them altogether. This time around, though, Thomas Gleixner vented his frustration on the linux-kernel list:

Nothing of this is 3.19 material so posting it right now is just useless. I'm not going to look at it and I'm not going to look at it next week either. This whole featuritis driven 'post crap as fast as you can' thing has to stop, really.

Posting patches during the merge window, he said, constitutes "maintainer abuse."

Some developers agreed with these sentiments, and Kevin Cernekee promptly posted (during the merge window, of course) a patch series titled "Stop maintainer abuse" trying to codify a rule that patches should not be posted during merge windows. Patches meant for the next merge window should, by these rules, be posted prior to the preceding -rc5 release; patches posted after -rc5 comes out will end up coming out one release later. And no patches at all, other than urgent fixes, should be posted while the merge window is open.

There is a potential problem, though, in that not all subsystem maintainers work the same way. Christoph Hellwig disagreed with the rules, saying:

Merge window isn't really special, and patches can easily be reviewed and queued up for the next merge window in that time. If it said you shouldn't expect replies and not _resend_ during the merge window that seems like a much saner policy.

Linus responded to the posting guidelines by noting that they don't apply equally to all maintainers:

[F]or fairly simple subsystems in particular, some maintainers basically have their pull requests for the merge window open *before* the merge window even starts, and for them, the merge window itself isn't actually all that busy, it's often the week before that is the busy one. So the exact timing can vary by maintainership, and while I think the above is a reasonable example, it should perhaps be documented as such.

Alan Cox worried that trying to put a lid on patch postings is always doomed to failure:

Every time anyone has tried to deal with Linux scaling problems by throttling the rate it has failed, from the near forking of it when Linus couldn't cope onwards. Today we are already seeing the same occurring with all the vendor trees, and shared downstream trees with a rapidly growing amount of stuff that simply isn't upstream because upstream can't keep up with actual product timescales any more.

His suggestion was to, instead, try to streamline the process a bit, mostly by improving the patchwork system to automate (or at least assist) many common maintainer duties. He finished by proposing that: "It could then be integrated into git (if only so we can have a 'git lost' command to block annoying sources)."

In the end, it is hard to see this problem being solved by either more rules or better tools. The creation of kernel patches continues at an increasing pace; the kernel community has to keep up with the flow somehow or suffer in the long run. In many cases, what may really be needed is more maintainers; some subsystems are now maintained by groups, but most of them are still managed by a single developer. Spreading the load would allow some maintainers to work on merge window issues while others keep track of the patch flow.

Such a change would require maintainers to allow others into their often fiercely guarded domains, though; the groups would also have to put time into developing a workflow that would work for them. It is not a simple or immediate solution, and it still will not address ills like developers who repost lengthy patch sets multiple times in one day. So, it seems, maintainers will still just have to get grumpy occasionally when developers push the boundaries too hard.

Index entries for this article
Kernel	Development model/Code review

to post comments

On the problem of maintainer abuse

Posted Dec 18, 2014 8:20 UTC (Thu) by hadess (subscriber, #24252) [Link] (2 responses)

I'm guessing that Thomas Gleixner doesn't receive many patches from drive-by committers, or by people "who can write kernel code" as opposed to "kernel developers".

I personally don't know when merge windows are, and my patches are sent when they're ready, and the maintainers I've had to deal with are nice enough to have queued those patches in branches until the merge window.

On the problem of maintainer abuse

Posted Dec 18, 2014 15:03 UTC (Thu) by bfields (subscriber, #19510) [Link] (1 responses)

I think you're probably fine.

Thomas Gleixner calls out three large patch series in his complaint. I'd guess they're regular developers hoping to get something into a particular kernel version at the last minute, as opposed to "drive-by"s just landing in the merge window by accident.

On the problem of maintainer abuse

Posted Dec 18, 2014 18:57 UTC (Thu) by bnorris (subscriber, #92090) [Link]

One of the series' cover letters [1] clearly states:

> For 3.19 you'll want the first patch at the minimum (because the build is currently broken).

I think that's sufficient reason for resending, and it certainly doesn't qualify as "featuritis driven 'post crap as fast as you can'".

[1] http://lwn.net/Articles/626139/

On the problem of maintainer abuse

Posted Dec 18, 2014 11:31 UTC (Thu) by dgm (subscriber, #49227) [Link] (1 responses)

If it's worth doing it, it's worth doing it BIG.- Let's think of a system able to cope with one billion developers, or so. Then we can throw it away (as any typical second system) and do it right.

My proposal is to charge a dollar for applied patch.
[rises pinkie and laughs]

On the problem of maintainer abuse

Posted Dec 19, 2014 14:43 UTC (Fri) by nix (subscriber, #2304) [Link]

At least the latter suggestion would stop 200-patch checkpatch-driven spew monsters changing nothing of import.