Re: [RFC 0/4] Stop maintainer abuse

[Paolo Bonzini]

On 16/12/2014 19:09, Jonathan Corbet wrote:
> In general, I worry about trying to codify things too much just because
> different maintainers have different expectations.  As Linus noted, some
> maintainers have their work done by the time the merge window starts and
> can take patches just fine â until something catches fire, at least.

As one of the recipients of the original evidence ("[v3 00/26] Add VT-d
Posted-Interrupts support"), I can only agree.

The timing of the series wasn't optimal for me, either: I do _not_ take
patches during the merge window and generally would like people that are
not KVM submaintainers to leave me alone.

On the other hand, the series is complex and spans four maintainers
(KVM, VFIO, IOMMU, x86), and it would be weird to blame people for
posting early.  In this case the x86 parts are just one patch out of 26.
 When x86 maintainers see something like this, they can expect the KVM
maintainer (me) to tell them "can you review the approach" or just "can
you give your Acked-by" once the rest of the series is mature.

As an example of a different workflow, generally things go like this for me:

   window   Put up fires, otherwise do non-kernel stuff

   rc1-rc2  Test large features, gather small patches in a rebased queue

   rc2-rc3  Big testing week: open next tree

   rc3-rc6  Merge small features

   rc6-     Merge bugfixes only, do non-kernel stuff, start bugging
            submaintainers

So for me the worst time to send patches is actually the week between
rc2 and rc3.  You're pretty much guaranteed to be ignored at that time,
unless of course the patch is for current mainline.

If you send during the merge window, chances are I'll be busy doing
something else and I won't have a fast turnaround.  But a mail from your
manager asking to merge a large feature after rc6 will definitely make
me more grumpy.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/