lkml.org 
[lkml]   [2014]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance
From
On Mon, Dec 15, 2014 at 6:59 AM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> 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


\
 
 \ /
  Last update: 2014-12-15 20:01    [W:0.107 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site