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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
