Re: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance
From: Linus Torvalds
Date: Mon Dec 15 2014 - 13:29:57 EST
On Mon, Dec 15, 2014 at 6:59 AM, One Thousand Gnomes
<gnomes@xxxxxxxxxxxxxxxxxxx> wrote:
>> +
>> + kernel.org "mainline:" | Patch may appear
>> + field when posted | in released kernel
>> + ------------------------+--------------------------------
>> + 3.18-rc[1-4] | 3.19
>> + 3.18-rc[5-9] | 3.20
>> + 3.18 | Merge window open - don't post
>> + 3.19-rc[1-4] | 3.20
>> + 3.19-rc[5-9] | 3.21
>> + 3.19 | Merge window open - don't post
>> +
>> +Bug fixes can typically be accepted at any time.
>
> That's exactly what was needed I think
So I don't think this is wrong per se, but I do think that it should
also have a clarification that
(a) the above "may appear" is basically "best possible timings", and
things can get delayed by various issues
(b) the exact timing is maintainer-specific.
For that (b) in particular, for fairly simple subsystems in
particular, some maintainers basically have their pull requests for
the merge window open *before* the merge window even starts, and for
them, the merge window itself isn't actually all that busy, it's often
the week before that is the busy one. So the exact timing can vary by
maintainership, and while I think the above is a reasonable example,
it should perhaps be documented as such. An *example*, not a "this is
how it always works". If you are preparing a 50-patch monster, I
suspect you may want to talk to the maintainer you're planning on
spamming before you send it out.
Linus
--
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/