[Ksummit-discuss] [TOPIC] Guidance for subsystem maintainers

josh at joshtriplett.org josh at joshtriplett.org
Tue May 13 16:28:44 UTC 2014


On Tue, May 13, 2014 at 07:57:16AM -0700, Sarah A Sharp wrote:
> Technical workflows will always be different.  I believe what Takashi
> is talking about is a social problem, not a technical problem.  Each
> maintainer needs some level of confidence in the patch, and thus some
> maintainers will wait a while before merging a patch, or wait for
> additional reviewers to ack it.  And sometimes that means the patch
> falls through the cracks.  Others will just throw the patch at their
> -next branch, do some quick testing, and catch bugs in the next -rc
> cycle.
> 
> Patch testing and review is a social problem, and trying to mandate a
> workflow or even a set of technical tools will not help solve the
> social problem of patches getting dropped or ignored.

Perhaps, but part of why Linus switched to git (and BK before that) was
to avoid the resend-patches-until-Linus-doesn't-drop-them-on-the-floor
problem.  It seems like we haven't so much *fixed* that problem as moved
it further down the chain to a subset of maintainers.

This holds even more true if you're trying to make a cross-subsystem
change: if you have 30 patches across 15 subsystems, you'll have a few
merged right away with an explicit email acknowledgement (notably Andrew
and Greg who have automated that), a few merged with no acknowledgement
(have fun finding where they got merged or figuring out where they'll go
from there), most of them disappear into a black hole until they
magically show up in Linus's tree two major versions in the future, and
a few just fall into /dev/null.  And I don't see an obvious way to
distinguish between the last three cases.

Two thoughts on that:

1) The cross-subsystem difficulties sometimes tempt me to queue up
patches into my own git tree and send direct pull requests to Linus once
I have a patch series that gets no objections from maintainers, but I'm
concerned about doing that for cross-subsystem "topics" and drawing
flames from subsystem maintainers about not going through their tree(s).
Is that a real problem, or is it considered reasonable to maintain a
repository by topic rather than by subsystem?  (I would, for instance,
be quite willing to maintain a "tiny" tree, and accept tinification
patches from others to merge upstream.)

2) We could improve the experience for patch submitters without
necessarily pushing changes to maintainer workflows.  I wonder if we
could do a better job of providing automated tools that make life easier
for maintainers and patch submitters?  For instance, what about having
easy-to-enable git hooks on git.kernel.org similar to those Andrew and
Greg use, notifying the patch submitter when a maintainer merges their
patch?  Maintainers could opt into those hooks specifically for
whichever repository has their "will go upstream eventually" branches,
and supply a short description of where patches typically flow from
their tree so submitters know what to expect.

Would that be useful?  Would maintainers want it?  What properties would
it need to have?  Could kernel.org support that?  And would anyone be
interested in helping to write it?  (I'm willing to help, given answers
to those questions to make sure it'll actually get *used*.)

- Josh Triplett


More information about the Ksummit-discuss mailing list