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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3909 bytes --]

On Tue, May 13, 2014 at 09:28:44AM -0700, josh@joshtriplett.org wrote:
> On Tue, May 13, 2014 at 07:57:16AM -0700, Sarah A Sharp wrote:

> > 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.

Indeed, and communicating best practice is part of helping to make
things work better.

> 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.

-next is *relatively* good for tracking things that are actually going
to Linus, though it's not a guarantee of course and does nothing for
the unresponsive case.

> 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.)

The main thing with these issues in terms of interpersonal conflict
avoidance mostly seems to be people talking to each other and cross tree
merges like Olof said.  The biggest issue I've seen with this stuff is
that it gets quite tedious seeing lots of reposts of frequently very
similar serieses as they go round and round loops which I fear tends to
encourage people to ignore such serieses.

> 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*.)

Meh, my artisan hand crafted "Applied, thanks" mails aren't good enough? :P

More seriously just getting some common place where people can work on
scripts would be useful even if they don't end up hosted on kernel.org.
I do have some scripts I use locally but they don't send replies, they
mainly just do patchwork for the trees I'm able to get patchwork working
for and remap my local git repo into the public branch names.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]