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

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

[Takashi Iwai]

... aka parent guide to healthy community care.

While posting to different subsystem areas, I noticed various ways of
responses and communications.  Some picks up quick, some urges more
reviews, sometimes a patch gets merged silently after months later,
etc.  Although the variety is one strength of OSS development, it made
me also wonder whether we need some baseline guidance for subsystem
maintenance in order to give a better appeal to casual developers.

Is such a thing too much burden to maintainers?  Or, is it just a
bikeshedding?


thanks,

Takashi

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

[Jiri Kosina]

On Tue, 13 May 2014, Takashi Iwai wrote:

> While posting to different subsystem areas, I noticed various ways of
> responses and communications.  Some picks up quick, some urges more
> reviews, sometimes a patch gets merged silently after months later,
> etc.  Although the variety is one strength of OSS development, it made
> me also wonder whether we need some baseline guidance for subsystem
> maintenance in order to give a better appeal to casual developers.
> 
> Is such a thing too much burden to maintainers?  Or, is it just a
> bikeshedding?

I am afraid that any attempt to force any working style on maintainers is 
pre-destined to fail.

As an example, there are folks who love patchwork and others wouldn't dare 
to touch it with a 10m pole.

Even such a "core" thing as git is explicitly claimed optional by Linus.

Is there perhaps anything more concrete you had on mind?

-- 
Jiri Kosina
SUSE Labs

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

[Takashi Iwai]

At Tue, 13 May 2014 16:31:49 +0200 (CEST),
Jiri Kosina wrote:
> 
> On Tue, 13 May 2014, Takashi Iwai wrote:
> 
> > While posting to different subsystem areas, I noticed various ways of
> > responses and communications.  Some picks up quick, some urges more
> > reviews, sometimes a patch gets merged silently after months later,
> > etc.  Although the variety is one strength of OSS development, it made
> > me also wonder whether we need some baseline guidance for subsystem
> > maintenance in order to give a better appeal to casual developers.
> > 
> > Is such a thing too much burden to maintainers?  Or, is it just a
> > bikeshedding?
> 
> I am afraid that any attempt to force any working style on maintainers is 
> pre-destined to fail.
> 
> As an example, there are folks who love patchwork and others wouldn't dare 
> to touch it with a 10m pole.
> 
> Even such a "core" thing as git is explicitly claimed optional by Linus.
> 
> Is there perhaps anything more concrete you had on mind?

Well, I haven't thought of any policy enforcement, either.  The way to
maintain codes (git, cvs or whatever) is a free choice, and the way
to communicate is also a free choice.  That's why I used a term
"guidance".

But something can be still helpful to be helpful.  For example, I
always spend long time just to look for how to report a bug in each
different subsystem.  Or, I become uneasy when a submitted patch don't
get any reaction for weeks (yeah, you learn to put always Andrew
Morton to Cc :) 
So, my concern is whether we built some obstacle unnecessarily in
front of our community, which might be improved by clarifying some
baseline.


Takashi

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

[Sarah A Sharp]

On Tue, May 13, 2014 at 7:31 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Tue, 13 May 2014, Takashi Iwai wrote:
>
>> While posting to different subsystem areas, I noticed various ways of
>> responses and communications.  Some picks up quick, some urges more
>> reviews, sometimes a patch gets merged silently after months later,
>> etc.  Although the variety is one strength of OSS development, it made
>> me also wonder whether we need some baseline guidance for subsystem
>> maintenance in order to give a better appeal to casual developers.
>>
>> Is such a thing too much burden to maintainers?  Or, is it just a
>> bikeshedding?
>
> I am afraid that any attempt to force any working style on maintainers is
> pre-destined to fail.
>
> As an example, there are folks who love patchwork and others wouldn't dare
> to touch it with a 10m pole.
>
> Even such a "core" thing as git is explicitly claimed optional by Linus.
>
> Is there perhaps anything more concrete you had on mind?

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.

Sarah Sharp

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

[Laurent Pinchart]

Hi Sarah,

On Tuesday 13 May 2014 07:57:16 Sarah A Sharp wrote:
> On Tue, May 13, 2014 at 7:31 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> > On Tue, 13 May 2014, Takashi Iwai wrote:
> >> While posting to different subsystem areas, I noticed various ways of
> >> responses and communications.  Some picks up quick, some urges more
> >> reviews, sometimes a patch gets merged silently after months later,
> >> etc.  Although the variety is one strength of OSS development, it made
> >> me also wonder whether we need some baseline guidance for subsystem
> >> maintenance in order to give a better appeal to casual developers.
> >> 
> >> Is such a thing too much burden to maintainers?  Or, is it just a
> >> bikeshedding?
> > 
> > I am afraid that any attempt to force any working style on maintainers is
> > pre-destined to fail.
> > 
> > As an example, there are folks who love patchwork and others wouldn't dare
> > to touch it with a 10m pole.
> > 
> > Even such a "core" thing as git is explicitly claimed optional by Linus.
> > 
> > Is there perhaps anything more concrete you had on mind?
> 
> 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.

Wouldn't it help if we could write down whatever rules that each subsystem 
maintainer found best ? For instance some maintainers expect to be CC'ed on 
patch submission, other prefer not to be CC'ed. When sending a patch to a new 
subsystem developers currently have no easy way to find this kind of 
information. We can of course expect them to do their homework and step in the 
subsystem to find out what's happening, but when modifying drivers across the 
whole kernel to support a new system that's a pretty large effort.

-- 
Regards,

Laurent Pinchart

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

[Stephen Warren]

On 05/13/2014 09:11 AM, Laurent Pinchart wrote:
...
> Wouldn't it help if we could write down whatever rules that each subsystem 
> maintainer found best ? For instance some maintainers expect to be CC'ed on 
> patch submission, other prefer not to be CC'ed. When sending a patch to a new 
> subsystem developers currently have no easy way to find this kind of 
> information.

Well, get_maintainers.pl spits out the list of destination email
addresses to send to. It should be easy enough to augment MAINTAINERS
entries with a flag (or different tag type) to say "I'm the maintainer
of this area, but I don't want to be CC'd on the email; just send it to
the list and I'll see it.", and have get_maintainers.pl print out that
information.

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

[josh]

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

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

[Olof Johansson]

On Tue, May 13, 2014 at 9:28 AM,  <josh@joshtriplett.org> wrote:
> 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.)

In your case I suspect we have little to no overlap between the code
we carry and merge and what you're looking to do, but for the sake of
general discussion:

We've been somewhat careful with these with arm-soc, since we merge
quite a bit of code from a lot of various platforms, and maybe once a
year we get something that isn't coordinated well enough and it
explodes into a very painful conflict-ridden mess the week before the
merge window opens.

The way we've chosen to avoid some of that is to merge in such topic
branches (once they're stable) as a base to have other platform
maintainers either base their branches off of, or at least we'll merge
in their branches on top of it so we catch the conflicts early and can
resolve them within our tree.

I.e. we're OK with doing it your way, but we want to know about it,
and if there's substantial overlap with other parts of our tree we'd
prefer to bring in the same branch into our tree as well. This of
course assumes it's not a controversial patch set and that it has been
out for proper reviews (and that it isn't done as an end-run around a
disagreeing maintainer).


-Olof

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

[Jiri Kosina]

On Tue, 13 May 2014, josh@joshtriplett.org wrote:

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

Good idea! I'd actually be very happy user of facility if it's provided by 
kernel.org.

Specifying a regexp on a branch name for which the automated e-mails 
should be sent out would suit my needs completely.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Mark Brown]

[-- 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 --]

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

[Jason Cooper]

On Tue, May 13, 2014 at 09:28:44AM -0700, josh@joshtriplett.org wrote:
...
> 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*.)

tip-bot might be a good place to start:

  http://git.zytor.com/linux/tip-bot.git

thx,

Jason.

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

[Mauro Carvalho Chehab]

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.

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.

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

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

> 
> - Josh Triplett
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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

[Josh Triplett]

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

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

[Linus Walleij]

On Tue, May 13, 2014 at 6:28 PM,  <josh@joshtriplett.org> wrote:

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

That would be awesome.

Yours,
Linus Walleij