Re: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance
On Mon, Dec 15, 2014 at 6:59 AM, One Thousand Gnomes 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance
> + > + 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 Acked-by: Alan Cox -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance
On Sun, Dec 14, 2014 at 10:09:49PM -0800, Kevin Cernekee wrote: > This has been a recurring source of confusion for the new submitters who > I've helped; let's see if adding a small illustration improves the > situation. > > Signed-off-by: Kevin Cernekee > --- > Documentation/development-process/5.Posting | 16 > 1 file changed, 16 insertions(+) > > diff --git a/Documentation/development-process/5.Posting > b/Documentation/development-process/5.Posting > index 14f8b01..50cf4dc 100644 > --- a/Documentation/development-process/5.Posting > +++ b/Documentation/development-process/5.Posting > @@ -35,6 +35,22 @@ 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. > > +In many cases, feature additions received and accepted somewhere in the range > +of [N-rc1, N-rc5) will be merged into the -next tree targeting the (N+1) > Linux > +release. For example: > + > + 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. Acked-by: Borislav Petkov -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance
On Sun, Dec 14, 2014 at 10:09:49PM -0800, Kevin Cernekee wrote: This has been a recurring source of confusion for the new submitters who I've helped; let's see if adding a small illustration improves the situation. Signed-off-by: Kevin Cernekee cerne...@gmail.com --- Documentation/development-process/5.Posting | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting index 14f8b01..50cf4dc 100644 --- a/Documentation/development-process/5.Posting +++ b/Documentation/development-process/5.Posting @@ -35,6 +35,22 @@ 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. +In many cases, feature additions received and accepted somewhere in the range +of [N-rc1, N-rc5) will be merged into the -next tree targeting the (N+1) Linux +release. For example: + + 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. Acked-by: Borislav Petkov b...@suse.de -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance
+ + 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 Acked-by: Alan Cox a...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/4] Documentation: Add cutoff periods for patch acceptance
On Mon, Dec 15, 2014 at 6:59 AM, One Thousand Gnomes gno...@lxorguk.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 3/4] Documentation: Add cutoff periods for patch acceptance
This has been a recurring source of confusion for the new submitters who I've helped; let's see if adding a small illustration improves the situation. Signed-off-by: Kevin Cernekee --- Documentation/development-process/5.Posting | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting index 14f8b01..50cf4dc 100644 --- a/Documentation/development-process/5.Posting +++ b/Documentation/development-process/5.Posting @@ -35,6 +35,22 @@ 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. +In many cases, feature additions received and accepted somewhere in the range +of [N-rc1, N-rc5) will be merged into the -next tree targeting the (N+1) Linux +release. For example: + + 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. + 5.2: BEFORE CREATING PATCHES -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 3/4] Documentation: Add cutoff periods for patch acceptance
This has been a recurring source of confusion for the new submitters who I've helped; let's see if adding a small illustration improves the situation. Signed-off-by: Kevin Cernekee cerne...@gmail.com --- Documentation/development-process/5.Posting | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting index 14f8b01..50cf4dc 100644 --- a/Documentation/development-process/5.Posting +++ b/Documentation/development-process/5.Posting @@ -35,6 +35,22 @@ 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. +In many cases, feature additions received and accepted somewhere in the range +of [N-rc1, N-rc5) will be merged into the -next tree targeting the (N+1) Linux +release. For example: + + 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. + 5.2: BEFORE CREATING PATCHES -- 2.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
