Ask patch submitters to avoid sending non-critical patches when the merge window is open. This basically extends the net-next policy in netdev-FAQ.txt to the entire kernel. Suggested-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> Signed-off-by: Kevin Cernekee <cernekee@xxxxxxxxx> --- Documentation/development-process/5.Posting | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting index 8a48c9b..14f8b01 100644 --- a/Documentation/development-process/5.Posting +++ b/Documentation/development-process/5.Posting @@ -26,6 +26,15 @@ which remains to be done and any known problems. Fewer people will look at patches which are known to be half-baked, but those who do will come in with the idea that they can help you drive the work in the right direction. +Some maintainers prefer to receive only urgent patches when the merge +window is open, so that critical fixes do not get lost in the noise during +times of peak activity. If you are posting an actual [PATCH] (not something +that is obviously low-priority such as an [RFC] or [RANT]) and you aren't sure +of your maintainer's stance, the safest thing to do is hold off until the +merge window has closed. You can visit https://www.kernel.org/ to check +the merge window status; it is closed if the "mainline:" entry shows a +version number containing "-rc", and open if a non-rc version number appears. + 5.2: BEFORE CREATING PATCHES -- 2.1.1 -- 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
