[lkml]   [2009]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: [RFC] Documentation: add documentation for rc-series and merge window
On Mon, Jun 15, 2009 at 01:19:34PM -0700, Greg KH wrote:
> On Mon, Jun 15, 2009 at 04:12:51PM -0400, Luis R. Rodriguez wrote:
> > This is losely based on previous discussions on linux-kernel [1][2].
> >
> > [1]
> > [2]
> >
> > Signed-off-by: Luis R. Rodriguez <>
> > ---
> >
> > I have run into issues when trying to explain this and policies
> > for the rc-series, it seems there is no place that documents this
> > clearly so here is an attempt based on some previous discussions.
> > Not sure if I got it all correct, so feedback is welcomed. I do think
> > clarifying this a little should help.
> >
> > I was also not sure if Documentation/stable_kernel_rules.txt is the best
> > splace for this as well, please let me know.
> I don't think this is the best place for it, as the stable_* file is for
> describing the rules for the 2.6.x.y releases, not the main 2.6.x
> releases.
> A new file perhaps? Or an addition to the
> Documentation/development-process/ book?

OK here is that, with Pavel's changes taken into consideration.

From: Luis R. Rodriguez <>
Subject: [PATCH] Documentation: add documentation summary for rc-series and merge window

This is losely based on previous discussions on linux-kernel [1][2].
Lets also refer people reading the stable rules to


Signed-off-by: Luis R. Rodriguez <>
Documentation/development-process/2.Process | 66 +++++++++++++++++++++++++++
Documentation/stable_kernel_rules.txt | 5 ++
2 files changed, 71 insertions(+), 0 deletions(-)

diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
index d750321..e023db6 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -7,6 +7,72 @@ course of one year, the kernel has since had to evolve a number of
processes to keep development happening smoothly. A solid understanding of
how the process works is required in order to be an effective part of it.

+This section provides a brief summary of the new kernel release rules.
+Stable kernels are released when they are ready! This means there are
+absolutely no strict guidelines for sticking to specific dates for a
+kernel release.
+The merge window opens up after the next stable kernel is released.
+The merge window is when maintainers of different subsystem send pull
+requests to Linus for code they have been queuing up for the next
+stable kernel. This is typically now done through respective
+foo-next-2.6.git trees where foo is your subsystem. Each maintainer
+queues up patches for the next kernel cycle in this foo-next-2.6.git
+tree. After the merge window the kernel is worked on through the
+rc-series of the kernel release.
+After a maintainer has sent his pull request to Linus during the merge
+window no further new development will be accepted for that tree and
+as such it marks the closure of development for that subsystem for that
+kernel cycle. Developers wishing to target deadlines should simply work
+on their development without regards or consideration for inclusion to
+a specific kernel release. Once development is done it should simply be
+posted. If you insist on targeting a kernel release for deadlines you can
+try to be aware of the current rc cycle development and how soon it seems
+the next stable kernel release will be made. When Linus notes the last rc
+cycle released may be the last -- that is a good sign you should already
+have all your development done and merged in the respective development
+tree. If your code is not ready and merged into the respective maintainers
+tree prior to the announced last potential rc kernel release chances are
+you missed getting your code in for the next kernel merge window.
+Exemptions here are new drivers, covered below.
+Rules on what kind of patches are accepted after the merge window closes.
+These are patches targeted for the kernel rc-series of a kernel prior
+to its release.
+ - it must fix a reported regression
+ - if must fix a reported security hole
+ - if must fix a reported oops/kernel hang
+This means any small-non-fix code changes, although they might fix an issue,
+will not be accepted. If the patch in question is for a driver that has been
+around for more than a kernel release, then "small fixes" really can't be
+worth all that much. And "small fixes" may be small and "obvious" they
+definitely can regress.
+The very first release a new driver (or filesystem) is special. New drivers
+are accepted during the rc series. Patches for the same driver then are
+also accepted during the same rc series of a kernel as well as fixes as it
+cannot regress as no previous kernels exists with it.
+Once drivers are upstream for one kernel release (say on 2.6.29) the target
+*goal* after the merge window of the next kernel (respectively this would be
+the 2.6.30 rc-series) is to address regressions. Kernel oops/hangs and security
+issues are obviously accepted but the point is these should have also been
+caught earlier as a general development goal. The rc-series focus should really
+be to address regressions.


diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index a452227..113e8c8 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -1,5 +1,10 @@
Everything you ever wanted to know about Linux 2.6 -stable releases.

+For further details, such as stable kernel release schedules, rc-series
+policies and process of development please refer to:
Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:


 \ /
  Last update: 2009-06-15 23:51    [W:0.098 / U:4.452 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site