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

[Josh Triplett <josh@joshtriplett.org>]

On Sun, May 18, 2014 at 12:09:56PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 13 May 2014 09:28:44 -0700 josh@joshtriplett.org escreveu:
> > 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).
> 
> The thing is that several of those cross-subsystem patches can cause
> merging issues, especially if they're changing some API that might
> also be used by other patches at the maintainer's trees/branches.

Certainly true.

> That's the hole point, IMHO, of having the acked-by tag: the maintainer
> is aware that such patch will be merged elsewhere, and will take the
> precautions to avoid issues at linux-next and upstream, if needed, when
> the patch gets merged.
> 
> I remember that I had to nack more than once some trivial patches that
> were touching a file that was about to be removed upstream, or whose
> lines of code it touched vanished.

Explicit acks and naks help, but it can be problematic to send 50
patches, get 10 acks, 3 naks, and 37 dead silences.

> > 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.)
> 
> Provided that you have the submaintainers ack, I don't see any problem
> on having such cross-subsystem topic branches.

That much makes sense, but I'm talking about the case of silence rather
than an ack.  Given a stack of patches with no objections but no
maintainer ack, does it make sense to just prepare a direct pull request
for Linus or Andrew, and assume that lack of objections suffices?

> > 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*.)
> 
> I like the idea of git hooks. I use it on the media tree I maintain. I can
> share the code of it, if you want.

That might help.  But I think point (2) is one that doesn't need
discussing at kernel summit; it just needs doing, by someone working in
cooperation with the kernel.org admins.

- Josh Triplett