linux-kernel - Re: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFz28Q2rOR5bLRiKs_SanROAHF5F1SPyQCqcFNwg2_Xk-w@mail.gmail.com>
Date:	Mon, 15 Dec 2014 10:29:50 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Kevin Cernekee <cernekee@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>,
	Brian Norris <computersforpeace@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance

On Mon, Dec 15, 2014 at 6:59 AM, One Thousand Gnomes
<gnomes@...rguk.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/