linux-kernel - Re: [RFC 0/4] Stop maintainer abuse

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]

Date:	Tue, 16 Dec 2014 14:19:02 -0800
From:	Kevin Cernekee <cernekee@...il.com>
To:	Jonathan Corbet <corbet@....net>
Cc:	Thomas Gleixner <tglx@...utronix.de>, bp@...en8.de,
	gnomes@...rguk.ukuu.org.uk,
	Brian Norris <computersforpeace@...il.com>,
	torvalds@...ux-foundation.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-doc@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 0/4] Stop maintainer abuse

On Tue, Dec 16, 2014 at 10:09 AM, Jonathan Corbet <corbet@....net> wrote:
> On Sun, 14 Dec 2014 22:09:46 -0800
> Kevin Cernekee <cernekee@...il.com> wrote:
>
>> This patch series amends the kernel development process to reduce the
>> load on key maintainers during peak periods, by discouraging the submission
>> of non-urgent patches while the merge window is open.
>
> You do understand the irony of posting this during the merge window,
> right? :)

I specifically exempted [RFC] from the rules because these threads are
readily distinguishable from urgent patches.  One could envision
setting up a procmail rule to move all [RFC] and [.*-next] messages
into a "save for later" folder.

> 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.

Do you think it might make sense to list the (stricter?) patch
acceptance policies in MAINTAINERS?

In the current process, many submitters do not know their maintainer's
policy until they get in trouble for violating it.  This is not a very
efficient way of educating people.  It might work if a submitter is
focusing most of his efforts on a small number of subsystems, with
which he becomes familiar over time.  But it doesn't work if somebody
has to touch many different areas of the kernel just once to e.g. add
support for a new SoC (including its syscon devices, irqchip drivers,
regulators, clocks, buses, and peripherals).
--
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/