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
