Re: [RFC 0/4] Stop maintainer abuse

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 16, 2014 at 10:09 AM, Jonathan Corbet <corbet@xxxxxxx> wrote:
> On Sun, 14 Dec 2014 22:09:46 -0800
> Kevin Cernekee <cernekee@xxxxxxxxx> 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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux