Maintainer abuse

Maintainer abuse

[Thomas Gleixner]

I'm really starting to get seriously grumpy about this.

Everyone is aware that we are in the middle of the merge window. So
this is definetely NOT the time to send anything else than urgent
bugfixes or the usual question/reply on something which was discussed
before.

I really consider it to be maintainer abuse to have

  [PATCH V5 00/23] Generic BMIPS kernel
  [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
  [v3 00/26] Add VT-d Posted-Interrupts support

i.e. 57 patches to look at in my inbox TODAY in the middle of the
merge window where I have to make other really more urgent
decisions.

Not to talk about the other patch series which arrived in the past few
days after the merge window opened. That sums up to a total of more
than 200 patches, some of them superseeded by now.

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. I'm observing the following patterns in a
frightingly increasing way:

 - Posting of massive patch sets right during or just before the merge
   window

 - Reposting of patchsets before the reviewer/maintainer had a chance
   to reply to ALL of N patches

This really has to stop.

Yours grumpy

      tglx


     

Re: Maintainer abuse

[Borislav Petkov]

On Sat, Dec 13, 2014 at 12:24:03AM +0100, Thomas Gleixner wrote:
>  - Posting of massive patch sets right during or just before the merge
>    window
> 
>  - Reposting of patchsets before the reviewer/maintainer had a chance
>    to reply to ALL of N patches

Absolutely agreed.

The rule of sending out patches and collecting feedback for a week at
least is not really being respected, from my experience. Shit gets
blasted out at the highest rate possible. Maybe lkml should have a
git-send-email throttle.

And I have the sneaking impression that a lot of people have not really
understood what merge window means.

> Yours grumpy

And then they wonder why reviewers/maintainers are grumpy.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Maintainer abuse

[One Thousand Gnomes]

On Sat, 13 Dec 2014 00:43:36 +0100
Borislav Petkov <bp@alien8.de> wrote:

> On Sat, Dec 13, 2014 at 12:24:03AM +0100, Thomas Gleixner wrote:
> >  - Posting of massive patch sets right during or just before the merge
> >    window
> > 
> >  - Reposting of patchsets before the reviewer/maintainer had a chance
> >    to reply to ALL of N patches
> 
> Absolutely agreed.
> 
> The rule of sending out patches and collecting feedback for a week at
> least is not really being respected, from my experience. Shit gets
> blasted out at the highest rate possible. Maybe lkml should have a
> git-send-email throttle.

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.

Leaving aside the small number of people who are just rude, there are
always going to be a lot of people who resend because they assume the
email was lost (as email is hopelessly unreliable nowdays), people who
don't understand, people whose managers don't understand, and people who
genuinely think their patch is important.

I'd ask two other questions instead

1. Why are they in your mailbox ?

Is it the year for a Google summer of code project or similar to turn
patchwork into a proper patch management tool (one that collects the
patches, provides a good maintainer interface, tells people automatically
that their patches are queued, deletes repeats, gives them status urls
they can give to managers or check, and also has the right bits
maintainer side to actually do stuff like send out "your patch set no
longer merges, please update" emails, and tell the maintainer if it
merges, the coding style important bits, etc and with buttons for "merge
me"

It could then be integrated into git (if only so we can have a "git lost"
command to block annoying sources)

2. Is X86 moving at a rate which needs some additional maintainers to
"maintain" the pending queue during merge windows and the like, and get
stuff into order for the maintainers proper ?

Alan

Re: Maintainer abuse

[Borislav Petkov]

On Sat, Dec 13, 2014 at 01:52:31PM +0000, One Thousand Gnomes wrote:

...

> It could then be integrated into git (if only so we can have a "git lost"
> command to block annoying sources)

All sounds nice and good but I'd be fine with people adhering to the
one-week feedback gather rule and not sending patchsets during the merge
window, for starters. I think those two will get us pretty far.

> 2. Is X86 moving at a rate which needs some additional maintainers to
> "maintain" the pending queue during merge windows and the like, and get
> stuff into order for the maintainers proper ?

Yep, no patches during the merge window should be a good start.

The rest of the time x86 actually scales pretty fine IMO.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: Maintainer abuse

[Thomas Gleixner]

On Sat, 13 Dec 2014, One Thousand Gnomes wrote:
> Is it the year for a Google summer of code project or similar to turn
> patchwork into a proper patch management tool (one that collects the
> patches, provides a good maintainer interface, tells people automatically
> that their patches are queued, deletes repeats, gives them status urls
> they can give to managers or check, and also has the right bits
> maintainer side to actually do stuff like send out "your patch set no
> longer merges, please update" emails, and tell the maintainer if it
> merges, the coding style important bits, etc and with buttons for "merge
> me"

If that works with command line tools which nicely integrate into
e-mail, that might be something useful. If it involves browser clicky
interfaces, then at least for me not so much.
 
> It could then be integrated into git (if only so we can have a "git lost"
> command to block annoying sources)
> 
> 2. Is X86 moving at a rate which needs some additional maintainers to
> "maintain" the pending queue during merge windows and the like, and get
> stuff into order for the maintainers proper ?

It usually works quite well. Just getting large patchsets sent in the
merge window or just right before it is a pain.

Thanks,

	tglx

Re: Maintainer abuse

[Brian Norris]

+ patchwork devs

On Mon, Dec 15, 2014 at 12:15:35PM +0100, Thomas Gleixner wrote:
> On Sat, 13 Dec 2014, One Thousand Gnomes wrote:
> > Is it the year for a Google summer of code project or similar to turn
> > patchwork into a proper patch management tool (one that collects the
> > patches, provides a good maintainer interface, tells people automatically
> > that their patches are queued, deletes repeats, gives them status urls
> > they can give to managers or check, and also has the right bits
> > maintainer side to actually do stuff like send out "your patch set no
> > longer merges, please update" emails, and tell the maintainer if it
> > merges, the coding style important bits, etc and with buttons for "merge
> > me"

Patchwork definitely could use some work to help it scale better. Your
todo list also sounds interesting.

> If that works with command line tools which nicely integrate into
> e-mail, that might be something useful. If it involves browser clicky
> interfaces, then at least for me not so much.

Patchwork has an XML-based RPC interface and a command-line 'pwclient'
tool which uses it. I've had moderate success hooking this into mutt
myself.

> > It could then be integrated into git (if only so we can have a "git lost"
> > command to block annoying sources)

Not sure exactly what this is referring to, but patchwork has a
rudimentary post-receive hook already which can be used to map patch
diffs back to their likely patch source and update its status
accordingly. e.g.,

   git push myremote HEAD:next

could mark all myremote/next..HEAD patches as 'Awaiting Upstream', and

   git push myremote HEAD:for-linus

could mark myremote/for-linus..HEAD as 'Accepted'. This is a bit of a
crapshoot if you haven't resolved the 'duplicate patches' problem
though.

Regards,
Brian

Re: Maintainer abuse

[Benjamin Herrenschmidt]

On Sat, 2014-12-13 at 00:24 +0100, Thomas Gleixner wrote:
> I'm really starting to get seriously grumpy about this.
> 
> Everyone is aware that we are in the middle of the merge window. So
> this is definetely NOT the time to send anything else than urgent
> bugfixes or the usual question/reply on something which was discussed
> before.
> 
> I really consider it to be maintainer abuse to have

 ../..

Picking up that thread late ... 

I might have myself been the culprit of that and I don't enforce such
policies on devs on powerpc either, as long as they don't have an
expectation of that stuff being merged before at best the next merge
window.

Especially RFC stuff. People are seeking comments about something or
some approach to a problem, this is clearly not intended for merging and
the comments might not necessarily have to come all from the maintainer,
so I don't see why posting to the list should adhere to a specific
rhythm.

I've certainly myself never taken much attention about when I was
sending a patch, only knew what to expect about when it might end up
being reviewed / merged.

Cheers,
Ben.

patch tracking tools (was Re: Maintainer abuse)

[Paolo Bonzini]

On 13/12/2014 14:52, One Thousand Gnomes wrote:
> Is it the year for a Google summer of code project or similar to turn
> patchwork into a proper patch management tool (one that collects the
> patches, provides a good maintainer interface, tells people automatically
> that their patches are queued, deletes repeats, gives them status urls
> they can give to managers or check, and also has the right bits
> maintainer side to actually do stuff like send out "your patch set no
> longer merges, please update" emails, and tell the maintainer if it
> merges, the coding style important bits, etc and with buttons for "merge
> me"

People from the QEMU project are working on something like this.

Right now the only public tool is "patches", which is a) a server that
gathers patch series and Reviewed-bys, and detects when they are
applied; b) a tool to query the list and also apply patches/pull
requests; c) a notmuch plugin that lets you query the list from Emacs.
The tool is pretty simple; the server produces a simple JSON file with
the patches from the last 30 days, the client tools download it and
operate on a local copy.

These tools are at https://github.com/stefanha/patches.  A sample
database is at http://wiki.qemu.org/patches/patches.json (you can play
with it: "patches fetch http://wiki.qemu.org/patches/patches.json").

If you want to see how a server is set up, see
https://github.com/stefanha/qemu-patches.

Also, we've added a "--message-id" to "git am" in order to help the
"patches" server detect what was applied.  The client tool already did
that when applying patches, but the next version of git will let
submaintainers contribute to the tracking even if they prefer "git am"
to "patches apply".

The "patches" tool is operated mostly from the command line.  There is
also a new tool in the works which scans the mailing list, applies what
it founds, checks it with checkpatch.pl, and compiles them.  It uses
Docker to quickly set up a compilation environment (and of course for
buzzword compliancy).  It also has a web interface that lets you do
simple searches.

This is more experimental and does not yet have a public instance
(source is at https://github.com/famz/patchew).

One thing that makes automation a bit easier for QEMU is that it does
not have a merge window; while we do have a central committer that takes
pull requests, the phases are a bit more traditional (2 month
development, 2 weeks preparation for freeze, 1 month feature freeze).
For Linux it would be more important for the tool to know which patches
are for which tree, possibly based on the destination mailing lists.

Paolo

Re: patch tracking tools (was Re: Maintainer abuse)

[Fam Zheng]

On Thu, 12/18 11:14, Paolo Bonzini wrote:
> 
> 
> On 13/12/2014 14:52, One Thousand Gnomes wrote:
> > Is it the year for a Google summer of code project or similar to turn
> > patchwork into a proper patch management tool (one that collects the
> > patches, provides a good maintainer interface, tells people automatically
> > that their patches are queued, deletes repeats, gives them status urls
> > they can give to managers or check, and also has the right bits
> > maintainer side to actually do stuff like send out "your patch set no
> > longer merges, please update" emails, and tell the maintainer if it
> > merges, the coding style important bits, etc and with buttons for "merge
> > me"
> 
> People from the QEMU project are working on something like this.
> 
> Right now the only public tool is "patches", which is a) a server that
> gathers patch series and Reviewed-bys, and detects when they are
> applied; b) a tool to query the list and also apply patches/pull
> requests; c) a notmuch plugin that lets you query the list from Emacs.
> The tool is pretty simple; the server produces a simple JSON file with
> the patches from the last 30 days, the client tools download it and
> operate on a local copy.
> 
> These tools are at https://github.com/stefanha/patches.  A sample
> database is at http://wiki.qemu.org/patches/patches.json (you can play
> with it: "patches fetch http://wiki.qemu.org/patches/patches.json").
> 
> If you want to see how a server is set up, see
> https://github.com/stefanha/qemu-patches.
> 
> Also, we've added a "--message-id" to "git am" in order to help the
> "patches" server detect what was applied.  The client tool already did
> that when applying patches, but the next version of git will let
> submaintainers contribute to the tracking even if they prefer "git am"
> to "patches apply".
> 
> The "patches" tool is operated mostly from the command line.  There is
> also a new tool in the works which scans the mailing list, applies what
> it founds, checks it with checkpatch.pl, and compiles them.  It uses
> Docker to quickly set up a compilation environment (and of course for
> buzzword compliancy).  It also has a web interface that lets you do
> simple searches.
> 
> This is more experimental and does not yet have a public instance
> (source is at https://github.com/famz/patchew).

FWIW, I've just setup an server instance today on a public available VM, which
is starting to subscribe to qemu-devel@nongnu.org and testing the patches:

http://209.132.179.37/

This tool wants to do two things to aid maintainers/reviewers:

1) Reply and complain if coding style violation / broken building / "make check"
failure is seen.

2) Provide an easy to use web interface to query patches.

> 
> One thing that makes automation a bit easier for QEMU is that it does
> not have a merge window; while we do have a central committer that takes
> pull requests, the phases are a bit more traditional (2 month
> development, 2 weeks preparation for freeze, 1 month feature freeze).
> For Linux it would be more important for the tool to know which patches
> are for which tree, possibly based on the destination mailing lists.

Things can be complicated, for example patch series dependencies.  It's a
question to think about whether we need it to be complete or want to keep it
simple.

I think such as a tool has to start as an auxiliary before becoming part of the
process.

Fam

Re: patch tracking tools (was Re: Maintainer abuse)

[Paolo Bonzini]

On 18/12/2014 14:25, Fam Zheng wrote:
> > One thing that makes automation a bit easier for QEMU is that it does
> > not have a merge window; while we do have a central committer that takes
> > pull requests, the phases are a bit more traditional (2 month
> > development, 2 weeks preparation for freeze, 1 month feature freeze).
> > For Linux it would be more important for the tool to know which patches
> > are for which tree, possibly based on the destination mailing lists.
>
> Things can be complicated, for example patch series dependencies.  It's a
> question to think about whether we need it to be complete or want to keep it
> simple.

I think we want to keep it simple.  Patch series dependencies complicate
the job for the maintainer too.

Andrea Arcangeli reminded me later of the obvious: for Linux such a tool
could simply use the linux-next tree as a base.

Paolo