This is losely based on previous discussions on linux-kernel [1][2].
[1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
[2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
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.
As a side note I'll say that I have noticed that it seems some companies
like to target getting stuff in by certain kernel releases, and for that
I think what may help is a heads up for when it seems each subsystem's
merge window will be closing up by.
I also realize the difficulty in trying to target certain schedules for a
kernel release but when that release date becomes clearer it would be nicer
to further communicate that accross the lists. Not sure if anything better
can be done today other than maybe highlighting more clearer on each rc release
where it seems we are. I myself try to track this on a google calendar and
it seems others do too [1]. One way or another as we get closer to a release
I think it would still be nicer to get more feedback to better predict this.
[1] http://lwn.net/Articles/253955/
Documentation/stable_kernel_rules.txt | 69 +++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index a452227..494baa5 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -1,5 +1,74 @@
Everything you ever wanted to know about Linux 2.6 -stable releases.
+Stable kernel releases
+----------------------
+
+Stable kernels are released when they are ready. This means there is no
+strict guidelines for sticking to specific dates for a kernel release.
+
+Merge window
+------------
+
+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 targetting 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 relase 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.
+Excemptions here are new drivers, covered below.
+
+rc-series rules
+---------------
+
+Rules on what kind of patches are accepted after the merge window closes.
+These are patches targetted 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 mix 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.
+
+rc-series new driver excemption rule
+------------------------------------
+
+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 uring 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 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.
+
+Stable kernel rules
+-------------------
+
Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:
--
1.6.2.2.446.gfbdc0
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] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
> [2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
>
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> ---
>
> 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?
thanks,
greg k-h
On Mon, Jun 15, 2009 at 04:12:51PM -0400, Luis R. Rodriguez wrote:
> I was also not sure if Documentation/stable_kernel_rules.txt is the best
> splace for this as well, please let me know.
I'm pretty sure it needs to be somewhere else. The -stable release
timing is basically unrelated to what your text discusses.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Mon, 2009-06-15 at 16:12 -0400, Luis R. Rodriguez wrote:
>
> +Stable kernel releases
> +----------------------
> +
> +Stable kernels are released when they are ready. This means there is no
> +strict guidelines for sticking to specific dates for a kernel release.
there are no strict guidelines
> +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 targetting a kernel release for deadlines you can
targeting
> +try to be aware of the current rc cycle development and how soon it seems
> +the next stable kernel relase will be made. When Linus notes the last rc
release
> +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.
> +Excemptions here are new drivers, covered below.
Exemptions
> +rc-series rules
> +---------------
> +
> +Rules on what kind of patches are accepted after the merge window closes.
> +These are patches targetted for the kernel rc-series of a kernel prior
targeted
> +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 mix fix an issue,
might fix
> +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.
> +
> +rc-series new driver excemption rule
exemption
> +------------------------------------
> +
> +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 uring the same rc series of a kernel as well as fixes as it
during
> +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 address regressions. Kernel oops/hangs
s/address address/address/
> +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.
> +
> +Stable kernel rules
> +-------------------
> +
> Rules on what kind of patches are accepted, and which ones are not, into the
> "-stable" tree:
Sorry, I'm in pedantic mood today.
--
Regards,
Pavel Roskin
On Mon, Jun 15, 2009 at 10:31 PM, Pavel Roskin<[email protected]> wrote:
> On Mon, 2009-06-15 at 16:12 -0400, Luis R. Rodriguez wrote:
>>
>> +Stable kernel releases
>> +----------------------
>> +
>> +Stable kernels are released when they are ready. This means there is no
>> +strict guidelines for sticking to specific dates for a kernel release.
>
> there are no strict guidelines
>
>> +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 targetting a kernel release for deadlines you can
>
> targeting
>
>> +try to be aware of the current rc cycle development and how soon it seems
>> +the next stable kernel relase will be made. When Linus notes the last rc
>
> release
>
>> +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.
>> +Excemptions here are new drivers, covered below.
>
> Exemptions
>
>> +rc-series rules
>> +---------------
>> +
>> +Rules on what kind of patches are accepted after the merge window closes.
>> +These are patches targetted for the kernel rc-series of a kernel prior
>
> targeted
>
>> +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 mix fix an issue,
>
> might fix
>
>> +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.
>> +
>> +rc-series new driver excemption rule
>
> exemption
>
>> +------------------------------------
>> +
>> +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 uring the same rc series of a kernel as well as fixes as it
>
> during
>
>> +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 address regressions. Kernel oops/hangs
>
> s/address address/address/
>
>> +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.
>> +
>> +Stable kernel rules
>> +-------------------
>> +
>> ?Rules on what kind of patches are accepted, and which ones are not, into the
>> ?"-stable" tree:
>
> Sorry, I'm in pedantic mood today.
At least you didn't end up making a spelling error in any of your
corrections. :-)
>
> --
> Regards,
> Pavel Roskin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
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] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
> > [2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
> >
> > Signed-off-by: Luis R. Rodriguez <[email protected]>
> > ---
> >
> > 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 <[email protected]>
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
Documentation/development-process/.
[1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
[2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
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.
+2.0 SUMMARY
+
+This section provides a brief summary of the new kernel release rules.
+
+2.0.0 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.
+
+2.0.1 MERGE WINDOW
+
+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.
+
+2.0.2 RC-SERIES RULES
+
+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.
+
+2.0.3 RC-SERIES NEW DRIVER EXEMPTION RULE
+
+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.
2.1: THE BIG PICTURE
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:
+
+Documentation/development-process/
+
Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:
--
1.6.2.2.446.gfbdc0
On Mon, Jun 15, 2009 at 05:47:35PM -0400, Luis R. Rodriguez wrote:
> From: Luis R. Rodriguez <[email protected]>
> 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
> Documentation/development-process/.
>
> [1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
> [2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
>
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> ---
> 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
You should cc: the author of this document, when modifying it.
> @@ -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.
>
> +2.0 SUMMARY
> +
> +This section provides a brief summary of the new kernel release rules.
> +
> +2.0.0 NEW KERNEL RELEASE RULES
"New"? We've been doing this for many many years now, what is "new"
about it?
And why are you starting a series with "0"? Just to keep from having to
modify all of the other numbers? None of the other files in this
directory start at 0...
thanks,
greg k-h
On Mon, Jun 15, 2009 at 03:32:06PM -0700, Greg KH wrote:
> On Mon, Jun 15, 2009 at 05:47:35PM -0400, Luis R. Rodriguez wrote:
> > From: Luis R. Rodriguez <[email protected]>
> > 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
> > Documentation/development-process/.
> >
> > [1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
> > [2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
> >
> > Signed-off-by: Luis R. Rodriguez <[email protected]>
> > ---
> > 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
>
> You should cc: the author of this document, when modifying it.
Added.
> > @@ -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.
> >
> > +2.0 SUMMARY
> > +
> > +This section provides a brief summary of the new kernel release rules.
> > +
> > +2.0.0 NEW KERNEL RELEASE RULES
>
> "New"? We've been doing this for many many years now, what is "new"
> about it?
New as in the next kernel release, sorry. Didn't mean as in "this is a
new process".
> And why are you starting a series with "0"? Just to keep from having to
> modify all of the other numbers? None of the other files in this
> directory start at 0...
Heh yeah.
Luis
On Mon, Jun 15, 2009 at 05:41:22PM -0700, Luis R. Rodriguez wrote:
> On Mon, Jun 15, 2009 at 03:32:06PM -0700, Greg KH wrote:
> > On Mon, Jun 15, 2009 at 05:47:35PM -0400, Luis R. Rodriguez wrote:
> > > From: Luis R. Rodriguez <[email protected]>
> > > 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
> > > Documentation/development-process/.
> > >
> > > [1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
> > > [2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
> > >
> > > Signed-off-by: Luis R. Rodriguez <[email protected]>
> > > ---
> > > 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
> >
> > You should cc: the author of this document, when modifying it.
>
> Added.
>
> > > @@ -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.
> > >
> > > +2.0 SUMMARY
> > > +
> > > +This section provides a brief summary of the new kernel release rules.
> > > +
> > > +2.0.0 NEW KERNEL RELEASE RULES
> >
> > "New"? We've been doing this for many many years now, what is "new"
> > about it?
>
> New as in the next kernel release, sorry. Didn't mean as in "this is a
> new process".
>
> > And why are you starting a series with "0"? Just to keep from having to
> > modify all of the other numbers? None of the other files in this
> > directory start at 0...
>
> Heh yeah.
OK here is v3 added some more stuff like number of days between releases
and an average for the last 10 releases.
From: Luis R. Rodriguez <[email protected]>
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
Documentation/development-process/.
Also add the number of days it has taken between releases,
and provide the average for the last 10 releases: 85.7 days.
[1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
[2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
Documentation/development-process/2.Process | 90 ++++++++++++++++++++++++---
Documentation/stable_kernel_rules.txt | 5 ++
2 files changed, 86 insertions(+), 9 deletions(-)
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
index d750321..9bbdd12 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -7,19 +7,91 @@ 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.
+2.0:SUMMARY
+
+This section provides a brief summary of the kernel release rules.
+
+2.0.0: 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.
+
+2.0.1: MERGE WINDOW
+
+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. The merge window closes at the first
+rc-series 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.
+
+2.0.2: RC-SERIES RULES
+
+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.
+
+2.0.3 RC-SERIES NEW DRIVER EXEMPTION RULE
+
+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.
2.1: THE BIG PICTURE
The kernel developers use a loosely time-based release process, with a new
-major kernel release happening every two or three months. The recent
-release history looks like this:
-
- 2.6.26 July 13, 2008
- 2.6.25 April 16, 2008
- 2.6.24 January 24, 2008
- 2.6.23 October 9, 2007
- 2.6.22 July 8, 2007
- 2.6.21 April 25, 2007
+major kernel release happening about every two or three months. The current
+average time based on the last 10 releases is 85.7 days. The recent release
+history along with the number of days between each release looks like this:
+
+ 2.6.30 June 10, 2009 - 79 days
+ 2.6.29 March 23, 2009 - 84 days
+ 2.6.28 December 29, 2008 - 82 days
+ 2.6.27 October 8, 2008 - 87 days
+ 2.6.26 July 13, 2008 - 88 days
+ 2.6.25 April 16, 2008 - 83 days
+ 2.6.24 January 24, 2008 - 107 days
+ 2.6.23 October 9, 2007 - 93 days
+ 2.6.22 July 8, 2007 - 74 days
+ 2.6.21 April 25, 2007 - 80 days
2.6.20 February 4, 2007
Every 2.6.x release is a major kernel release with new features, internal
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:
+
+Documentation/development-process/
+
Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:
--
1.6.2.2.446.gfbdc0
On Mon, Jun 15, 2009 at 10:10:11PM -0400, Luis R. Rodriguez wrote:
> + 2.6.30 June 10, 2009 - 79 days
> + 2.6.29 March 23, 2009 - 84 days
> + 2.6.28 December 29, 2008 - 82 days
> + 2.6.27 October 8, 2008 - 87 days
> + 2.6.26 July 13, 2008 - 88 days
> + 2.6.25 April 16, 2008 - 83 days
> + 2.6.24 January 24, 2008 - 107 days
> + 2.6.23 October 9, 2007 - 93 days
> + 2.6.22 July 8, 2007 - 74 days
> + 2.6.21 April 25, 2007 - 80 days
> 2.6.20 February 4, 2007
Are you sure about those dates and the count of number of days?
According to my "big spreadsheet of kernel releases", your day count is
wrong...
I have:
release: v2.6.20 v2.6.21 v2.6.22 v2.6.23 v2.6.24 v2.6.25 v2.6.26 v2.6.27 v2.6.28 v2.6.29 v2.6.30
date: 02/04/07 04/25/07 07/08/07 10/09/07 01/24/08 04/16/08 07/13/08 10/09/08 12/24/08 03/23/09 06/09/09
# Days: 68 81 75 94 108 83 88 88 76 89 78
thanks,
greg k-h
On Mon, Jun 15, 2009 at 08:20:34PM -0700, Greg KH wrote:
> On Mon, Jun 15, 2009 at 10:10:11PM -0400, Luis R. Rodriguez wrote:
> > + 2.6.30 June 10, 2009 - 79 days
> > + 2.6.29 March 23, 2009 - 84 days
> > + 2.6.28 December 29, 2008 - 82 days
> > + 2.6.27 October 8, 2008 - 87 days
> > + 2.6.26 July 13, 2008 - 88 days
> > + 2.6.25 April 16, 2008 - 83 days
> > + 2.6.24 January 24, 2008 - 107 days
> > + 2.6.23 October 9, 2007 - 93 days
> > + 2.6.22 July 8, 2007 - 74 days
> > + 2.6.21 April 25, 2007 - 80 days
> > 2.6.20 February 4, 2007
>
> Are you sure about those dates and the count of number of days?
I used this cheesy web app:
http://www.timeanddate.com/date/duration.html
So it could have told 42 for all answers I suppose and I wouldn't have known
the difference. BTW does your list count the ending date? That is from say
01-01-2009 to 01-02-2009 does it count 2 or 1? I set it to not count it.
> According to my "big spreadsheet of kernel releases", your day count is
> wrong...
>
> I have:
>
> release: v2.6.20 v2.6.21 v2.6.22 v2.6.23 v2.6.24 v2.6.25 v2.6.26 v2.6.27 v2.6.28 v2.6.29 v2.6.30
> date: 02/04/07 04/25/07 07/08/07 10/09/07 01/24/08 04/16/08 07/13/08 10/09/08 12/24/08 03/23/09 06/09/09
> # Days: 68 81 75 94 108 83 88 88 76 89 78
I'll trust your big spreadsheet more and with it you actually get a nice
even 86.0 average.
Here is a new patch based on your spreadsheet info.
From: Luis R. Rodriguez <[email protected]>
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
Documentation/development-process/.
Also add the number of days it has taken between releases,
and provide the average for the last 10 releases: 86.0 days.
[1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
[2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
Documentation/development-process/2.Process | 92 ++++++++++++++++++++++++---
Documentation/stable_kernel_rules.txt | 5 ++
2 files changed, 87 insertions(+), 10 deletions(-)
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
index d750321..668eb8f 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -7,20 +7,92 @@ 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.
+2.0:SUMMARY
+
+This section provides a brief summary of the kernel release rules.
+
+2.0.0: 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.
+
+2.0.1: MERGE WINDOW
+
+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. The merge window closes at the first
+rc-series 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.
+
+2.0.2: RC-SERIES RULES
+
+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.
+
+2.0.3 RC-SERIES NEW DRIVER EXEMPTION RULE
+
+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.
2.1: THE BIG PICTURE
The kernel developers use a loosely time-based release process, with a new
-major kernel release happening every two or three months. The recent
-release history looks like this:
-
- 2.6.26 July 13, 2008
- 2.6.25 April 16, 2008
- 2.6.24 January 24, 2008
- 2.6.23 October 9, 2007
- 2.6.22 July 8, 2007
- 2.6.21 April 25, 2007
- 2.6.20 February 4, 2007
+major kernel release happening about every two or three months. The current
+average time based on the last 10 releases is 86.0 days. The recent release
+history along with the number of days between each release looks like this:
+
+ 2.6.30 June 10, 2009 - 78 days
+ 2.6.29 March 23, 2009 - 89 days
+ 2.6.28 December 29, 2008 - 76 days
+ 2.6.27 October 8, 2008 - 88 days
+ 2.6.26 July 13, 2008 - 88 days
+ 2.6.25 April 16, 2008 - 83 days
+ 2.6.24 January 24, 2008 - 108 days
+ 2.6.23 October 9, 2007 - 94 days
+ 2.6.22 July 8, 2007 - 75 days
+ 2.6.21 April 25, 2007 - 81 days
+ 2.6.20 February 4, 2007 - 68
Every 2.6.x release is a major kernel release with new features, internal
API changes, and more. A typical 2.6 release can contain over 10,000
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:
+
+Documentation/development-process/
+
Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:
--
1.6.2.2.446.gfbdc0
On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis Rodriguez wrote:
> On Mon, Jun 15, 2009 at 08:20:34PM -0700, Greg KH wrote:
> > On Mon, Jun 15, 2009 at 10:10:11PM -0400, Luis R. Rodriguez wrote:
> > > + 2.6.30 June 10, 2009 - 79 days
> > > + 2.6.29 March 23, 2009 - 84 days
> > > + 2.6.28 December 29, 2008 - 82 days
> > > + 2.6.27 October 8, 2008 - 87 days
> > > + 2.6.26 July 13, 2008 - 88 days
> > > + 2.6.25 April 16, 2008 - 83 days
> > > + 2.6.24 January 24, 2008 - 107 days
> > > + 2.6.23 October 9, 2007 - 93 days
> > > + 2.6.22 July 8, 2007 - 74 days
> > > + 2.6.21 April 25, 2007 - 80 days
> > > 2.6.20 February 4, 2007
> >
> > Are you sure about those dates and the count of number of days?
>
> I used this cheesy web app:
>
> http://www.timeanddate.com/date/duration.html
>
> So it could have told 42 for all answers I suppose and I wouldn't have known
> the difference. BTW does your list count the ending date? That is from say
> 01-01-2009 to 01-02-2009 does it count 2 or 1? I set it to not count it.
>
> > According to my "big spreadsheet of kernel releases", your day count is
> > wrong...
> >
> > I have:
> >
> > release: v2.6.20 v2.6.21 v2.6.22 v2.6.23 v2.6.24 v2.6.25 v2.6.26 v2.6.27 v2.6.28 v2.6.29 v2.6.30
> > date: 02/04/07 04/25/07 07/08/07 10/09/07 01/24/08 04/16/08 07/13/08 10/09/08 12/24/08 03/23/09 06/09/09
> > # Days: 68 81 75 94 108 83 88 88 76 89 78
>
> I'll trust your big spreadsheet more and with it you actually get a nice
> even 86.0 average.
FWIW using the same cheesy web app, if we do go about the 10 kernel release
average of 86.0 days the next 2.6.31 release should be September 4, 2009.
Luis
On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis R. Rodriguez wrote:
> So it could have told 42 for all answers I suppose and I wouldn't have known
> the difference. BTW does your list count the ending date? That is from say
> 01-01-2009 to 01-02-2009 does it count 2 or 1? I set it to not count it.
I don't know, but at least it is consistant :)
It is whatever openoffice uses when calculating dates subtracted from
each other.
thanks,
greg k-h
On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis R. Rodriguez wrote:
> +2.0.2: RC-SERIES RULES
> +
> +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
s/if/it/ twice..
Is there a good reason for documenting different rules for rc-series and
-stable releases? These three rules look stricter than the ones
described in stable_kernel_rules.txt:
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
critical.
For example, a fix for data corruption that users can hit relatively
easily sounds like a good example of something that should really be
accepted during the rc-phase even if it is not really a regression or
does not cause a kernel oops/hang.
"oh, that's not good" issue is somewhat more difficult to comment on,
but I would expect that there could be some critical issues that really
would benefit from an exception. What exactly would qualify is something
that may be not be easily described in a sentence or two, though.
The main problem I see with having a very hard line on not allowing
critical fixes (however that would be defined) during the rc-phase is
that it will take quite a long time to get the fix eventually out. As an
example, a driver could have a bug that prevents it from working with
certain subset of devices, but this is noticed only couple of kernel
releases after the initial driver merge (e.g., for hardware that was not
yet available for end users at the time the driver was initially
submitted). In other words, the issue would not be a regression, not a
security hole, and not an oops/kernel hang. However, it could make the
driver unusable to large number of users (once the affected hardware
model becomes available; say in a new laptop).
If an issue is fixed just before a start of the next merge window the
patch may not have had enough time to go through the maintainers and end
up in linux-2.6.git in time before the merge window closes. If it
weren't now allowed in during the rc-phase, it may not go into a stable
release either (assuming the rc/stable rules are more or less the same)
and we would be looking something like five month time until the fix
would actually be released in a proper kernel release. Sure,
users/distros could take in some additional patches to fix issues they
care about, but worst case scenarios of close to half a year to fix an
issue in a kernel release does not sound quite ideal.
--
Jouni Malinen PGP id EFC895FA
Jouni Malinen wrote:
> If it
> weren't now allowed in during the rc-phase, it may not go into a stable
> release either (assuming the rc/stable rules are more or less the same)
They aren't.
Just compare shortlogs between -RCs with shortlogs between .Ys and
everything becomes almost obvious. :-)
--
Stefan Richter
-=====-==--= -==- =----
http://arcgraph.de/sr/
On Tue, Jun 16, 2009 at 02:34:01AM -0700, Jouni Malinen wrote:
> On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis R. Rodriguez wrote:
>
> > +2.0.2: RC-SERIES RULES
> > +
> > +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
>
>
> s/if/it/ twice..
Thanks, fixed.
> Is there a good reason for documenting different rules for rc-series and
> -stable releases? These three rules look stricter than the ones
> described in stable_kernel_rules.txt:
>
> - It must fix a problem that causes a build error (but not for things
> marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> security issue, or some "oh, that's not good" issue. In short, something
> critical.
The rc-series rules this patch adds are a summary, so they do indeed appear to be
stricter but I do think new vendor/device ids should be welcomed as well AFAICT,
for instance.
What may be best is to merge these two somehow and refer to the common rules for
both and try to differentiate between them in their respective documentation
section.
But I also think good judgement can be applied, good judgement being defined as
that of a subsystem maintainer, which allows us to simply tell developers to
focus on development and send patches up and the respective maintainer routes
the fixes accordingly.
The spirit of writig this summary is to be clear that rules do exist and that
we cannot simply suggest to read stable_kernel_rules.txt as there are items there
which do not apply.
Reason for trying to add more documentation for this is today there are a lot
companies are working upstream and a better sense of what can get into specific
kernel releases becomes more important and you also have more responsible
developers looking out to ensure their fixes get propagated to the right trees.
So leaving some of these things undocumented, implied or in the dark can turn
out to not be as healthy and IMHO is what lead to the original issue from which
I extracted information to create this summary.
> For example, a fix for data corruption that users can hit relatively
> easily sounds like a good example of something that should really be
> accepted during the rc-phase even if it is not really a regression or
> does not cause a kernel oops/hang.
Agreed.
> "oh, that's not good" issue is somewhat more difficult to comment on,
> but I would expect that there could be some critical issues that really
> would benefit from an exception. What exactly would qualify is something
> that may be not be easily described in a sentence or two, though.
>
>
> The main problem I see with having a very hard line on not allowing
> critical fixes (however that would be defined) during the rc-phase is
> that it will take quite a long time to get the fix eventually out. As an
> example, a driver could have a bug that prevents it from working with
> certain subset of devices, but this is noticed only couple of kernel
> releases after the initial driver merge (e.g., for hardware that was not
> yet available for end users at the time the driver was initially
> submitted).
I believe it makes sense to send fixes for new hardware on an old
driver if it is known the fix cannot regress as it does not affect older
hardware.
> In other words, the issue would not be a regression, not a
> security hole, and not an oops/kernel hang. However, it could make the
> driver unusable to large number of users (once the affected hardware
> model becomes available; say in a new laptop).
Agreed. But I think that would fall under the new driver category.
> If an issue is fixed just before a start of the next merge window the
> patch may not have had enough time to go through the maintainers and end
> up in linux-2.6.git in time before the merge window closes. If it
> weren't now allowed in during the rc-phase, it may not go into a stable
> release either (assuming the rc/stable rules are more or less the same)
> and we would be looking something like five month time until the fix
> would actually be released in a proper kernel release. Sure,
> users/distros could take in some additional patches to fix issues they
> care about, but worst case scenarios of close to half a year to fix an
> issue in a kernel release does not sound quite ideal.
Agreed. In the end it seems to come down to the specifics of the patch and
only the maintainer can really be a good judge of whether it should go in
or not. Of course properly documenting each patch helps, and I believe that
in itself may be good enough to address the grey areas.
Here's a new patch with the fix you noted. Also added a little stub about
maintainers judgement, etc.
From: Luis R. Rodriguez <[email protected]>
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
Documentation/development-process/.
Also add the number of days it has taken between releases,
and provide the average for the last 10 releases: 86.0 days.
[1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
[2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
Documentation/development-process/2.Process | 96 ++++++++++++++++++++++++---
Documentation/stable_kernel_rules.txt | 5 ++
2 files changed, 91 insertions(+), 10 deletions(-)
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
index d750321..c220646 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -7,20 +7,96 @@ 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.
+2.0:SUMMARY
+
+This section provides a brief summary of the kernel release rules.
+
+2.0.0: 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.
+
+2.0.1: MERGE WINDOW
+
+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. The merge window closes at the first
+rc-series 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.
+
+2.0.2: RC-SERIES RULES
+
+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
+ - it must fix a reported security hole
+ - it 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.
+
+When in doubt consult with your subsystem maintainer or just allow him to
+do the judging of where the patches deserves to go to, a proper commit log
+should help with this effort.
+
+2.0.3 RC-SERIES NEW DRIVER EXEMPTION RULE
+
+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.
2.1: THE BIG PICTURE
The kernel developers use a loosely time-based release process, with a new
-major kernel release happening every two or three months. The recent
-release history looks like this:
-
- 2.6.26 July 13, 2008
- 2.6.25 April 16, 2008
- 2.6.24 January 24, 2008
- 2.6.23 October 9, 2007
- 2.6.22 July 8, 2007
- 2.6.21 April 25, 2007
- 2.6.20 February 4, 2007
+major kernel release happening about every two or three months. The current
+average time based on the last 10 releases is 86.0 days. The recent release
+history along with the number of days between each release looks like this:
+
+ 2.6.30 June 10, 2009 - 78 days
+ 2.6.29 March 23, 2009 - 89 days
+ 2.6.28 December 29, 2008 - 76 days
+ 2.6.27 October 8, 2008 - 88 days
+ 2.6.26 July 13, 2008 - 88 days
+ 2.6.25 April 16, 2008 - 83 days
+ 2.6.24 January 24, 2008 - 108 days
+ 2.6.23 October 9, 2007 - 94 days
+ 2.6.22 July 8, 2007 - 75 days
+ 2.6.21 April 25, 2007 - 81 days
+ 2.6.20 February 4, 2007 - 68
Every 2.6.x release is a major kernel release with new features, internal
API changes, and more. A typical 2.6 release can contain over 10,000
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:
+
+Documentation/development-process/
+
Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:
--
1.6.2.2.446.gfbdc0
On Tue 2009-06-16 11:17:05, Luis R. Rodriguez wrote:
> On Tue, Jun 16, 2009 at 02:34:01AM -0700, Jouni Malinen wrote:
> > On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis R. Rodriguez wrote:
> >
> > > +2.0.2: RC-SERIES RULES
> > > +
> > > +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
> >
> >
> > s/if/it/ twice..
>
> Thanks, fixed.
>
> > Is there a good reason for documenting different rules for rc-series and
> > -stable releases? These three rules look stricter than the ones
> > described in stable_kernel_rules.txt:
> >
> > - It must fix a problem that causes a build error (but not for things
> > marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> > security issue, or some "oh, that's not good" issue. In short, something
> > critical.
>
> The rc-series rules this patch adds are a summary, so they do indeed appear to be
> stricter but I do think new vendor/device ids should be welcomed as well AFAICT,
> for instance.
>
> What may be best is to merge these two somehow and refer to the common rules for
> both and try to differentiate between them in their respective documentation
> section.
>
> But I also think good judgement can be applied, good judgement being defined as
> that of a subsystem maintainer, which allows us to simply tell developers to
> focus on development and send patches up and the respective maintainer routes
> the fixes accordingly.
>
> The spirit of writig this summary is to be clear that rules do exist and that
> we cannot simply suggest to read stable_kernel_rules.txt as there are items there
> which do not apply.
>
> Reason for trying to add more documentation for this is today there are a lot
> companies are working upstream and a better sense of what can get into specific
> kernel releases becomes more important and you also have more responsible
> developers looking out to ensure their fixes get propagated to the right trees.
> So leaving some of these things undocumented, implied or in the dark can turn
> out to not be as healthy and IMHO is what lead to the original issue from which
> I extracted information to create this summary.
>
> > For example, a fix for data corruption that users can hit relatively
> > easily sounds like a good example of something that should really be
> > accepted during the rc-phase even if it is not really a regression or
> > does not cause a kernel oops/hang.
>
> Agreed.
>
> > "oh, that's not good" issue is somewhat more difficult to comment on,
> > but I would expect that there could be some critical issues that really
> > would benefit from an exception. What exactly would qualify is something
> > that may be not be easily described in a sentence or two, though.
> >
> >
> > The main problem I see with having a very hard line on not allowing
> > critical fixes (however that would be defined) during the rc-phase is
> > that it will take quite a long time to get the fix eventually out. As an
> > example, a driver could have a bug that prevents it from working with
> > certain subset of devices, but this is noticed only couple of kernel
> > releases after the initial driver merge (e.g., for hardware that was not
> > yet available for end users at the time the driver was initially
> > submitted).
>
> I believe it makes sense to send fixes for new hardware on an old
> driver if it is known the fix cannot regress as it does not affect older
> hardware.
>
> > In other words, the issue would not be a regression, not a
> > security hole, and not an oops/kernel hang. However, it could make the
> > driver unusable to large number of users (once the affected hardware
> > model becomes available; say in a new laptop).
>
> Agreed. But I think that would fall under the new driver category.
>
> > If an issue is fixed just before a start of the next merge window the
> > patch may not have had enough time to go through the maintainers and end
> > up in linux-2.6.git in time before the merge window closes. If it
> > weren't now allowed in during the rc-phase, it may not go into a stable
> > release either (assuming the rc/stable rules are more or less the same)
> > and we would be looking something like five month time until the fix
> > would actually be released in a proper kernel release. Sure,
> > users/distros could take in some additional patches to fix issues they
> > care about, but worst case scenarios of close to half a year to fix an
> > issue in a kernel release does not sound quite ideal.
>
> Agreed. In the end it seems to come down to the specifics of the patch and
> only the maintainer can really be a good judge of whether it should go in
> or not. Of course properly documenting each patch helps, and I believe that
> in itself may be good enough to address the grey areas.
>
> Here's a new patch with the fix you noted. Also added a little stub about
> maintainers judgement, etc.
>
> From: Luis R. Rodriguez <[email protected]>
> 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
> Documentation/development-process/.
>
> Also add the number of days it has taken between releases,
> and provide the average for the last 10 releases: 86.0 days.
>
> [1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
> [2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
>
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> ---
> Documentation/development-process/2.Process | 96 ++++++++++++++++++++++++---
> Documentation/stable_kernel_rules.txt | 5 ++
> 2 files changed, 91 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
> index d750321..c220646 100644
> --- a/Documentation/development-process/2.Process
> +++ b/Documentation/development-process/2.Process
> @@ -7,20 +7,96 @@ 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.
>
> +2.0:SUMMARY
> +
> +This section provides a brief summary of the kernel release rules.
> +
> +2.0.0: 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.
> +
> +2.0.1: MERGE WINDOW
> +
> +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. The merge window closes at the first
> +rc-series 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.
> +
> +2.0.2: RC-SERIES RULES
> +
> +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
> + - it must fix a reported security hole
> + - it must fix a reported oops/kernel hang
- it must fix a bug.
I do not think the 'reported' requirement is there in -rc, and yes,
compile-fixes etc are welcome. Non-intrusive bugfixes too, afaict.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, Jun 19, 2009 at 8:00 AM, Pavel Machek<[email protected]> wrote:
> On Tue 2009-06-16 11:17:05, Luis R. Rodriguez wrote:
>> On Tue, Jun 16, 2009 at 02:34:01AM -0700, Jouni Malinen wrote:
>> > On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis R. Rodriguez wrote:
>> >
>> > > +2.0.2: RC-SERIES RULES
>> > > +
>> > > +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
>> >
>> >
>> > s/if/it/ twice..
>>
>> Thanks, fixed.
>>
>> > Is there a good reason for documenting different rules for rc-series and
>> > -stable releases? These three rules look stricter than the ones
>> > described in stable_kernel_rules.txt:
>> >
>> > - It must fix a problem that causes a build error (but not for things
>> > marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>> > security issue, or some "oh, that's not good" issue. In short, something
>> > critical.
>>
>> The rc-series rules this patch adds are a summary, so they do indeed appear to be
>> stricter but I do think new vendor/device ids should be welcomed as well AFAICT,
>> for instance.
>>
>> What may be best is to merge these two somehow and refer to the common rules for
>> both and try to differentiate between them in their respective documentation
>> section.
>>
>> But I also think good judgement can be applied, good judgement being defined as
>> that of a subsystem maintainer, which allows us to simply tell developers to
>> focus on development and send patches up and the respective maintainer routes
>> the fixes accordingly.
>>
>> The spirit of writig this summary is to be clear that rules do exist and that
>> we cannot simply suggest to read stable_kernel_rules.txt as there are items there
>> which do not apply.
>>
>> Reason for trying to add more documentation for this is today there are a lot
>> companies are working upstream and a better sense of what can get into specific
>> kernel releases becomes more important and you also have more responsible
>> developers looking out to ensure their fixes get propagated to the right trees.
>> So leaving some of these things undocumented, implied or in the dark can turn
>> out to not be as healthy and IMHO is what lead to the original issue from which
>> I extracted information to create this summary.
>>
>> > For example, a fix for data corruption that users can hit relatively
>> > easily sounds like a good example of something that should really be
>> > accepted during the rc-phase even if it is not really a regression or
>> > does not cause a kernel oops/hang.
>>
>> Agreed.
>>
>> > "oh, that's not good" issue is somewhat more difficult to comment on,
>> > but I would expect that there could be some critical issues that really
>> > would benefit from an exception. What exactly would qualify is something
>> > that may be not be easily described in a sentence or two, though.
>> >
>> >
>> > The main problem I see with having a very hard line on not allowing
>> > critical fixes (however that would be defined) during the rc-phase is
>> > that it will take quite a long time to get the fix eventually out. As an
>> > example, a driver could have a bug that prevents it from working with
>> > certain subset of devices, but this is noticed only couple of kernel
>> > releases after the initial driver merge (e.g., for hardware that was not
>> > yet available for end users at the time the driver was initially
>> > submitted).
>>
>> I believe it makes sense to send fixes for new hardware on an old
>> driver if it is known the fix cannot regress as it does not affect older
>> hardware.
>>
>> > In other words, the issue would not be a regression, not a
>> > security hole, and not an oops/kernel hang. However, it could make the
>> > driver unusable to large number of users (once the affected hardware
>> > model becomes available; say in a new laptop).
>>
>> Agreed. But I think that would fall under the new driver category.
>>
>> > If an issue is fixed just before a start of the next merge window the
>> > patch may not have had enough time to go through the maintainers and end
>> > up in linux-2.6.git in time before the merge window closes. If it
>> > weren't now allowed in during the rc-phase, it may not go into a stable
>> > release either (assuming the rc/stable rules are more or less the same)
>> > and we would be looking something like five month time until the fix
>> > would actually be released in a proper kernel release. Sure,
>> > users/distros could take in some additional patches to fix issues they
>> > care about, but worst case scenarios of close to half a year to fix an
>> > issue in a kernel release does not sound quite ideal.
>>
>> Agreed. In the end it seems to come down to the specifics of the patch and
>> only the maintainer can really be a good judge of whether it should go in
>> or not. Of course properly documenting each patch helps, and I believe that
>> in itself may be good enough to address the grey areas.
>>
>> Here's a new patch with the fix you noted. Also added a little stub about
>> maintainers judgement, etc.
>>
>> From: Luis R. Rodriguez <[email protected]>
>> 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
>> Documentation/development-process/.
>>
>> Also add the number of days it has taken between releases,
>> and provide the average for the last 10 releases: 86.0 days.
>>
>> [1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
>> [2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
>>
>> Signed-off-by: Luis R. Rodriguez <[email protected]>
>> ---
>> Documentation/development-process/2.Process | 96 ++++++++++++++++++++++++---
>> Documentation/stable_kernel_rules.txt | 5 ++
>> 2 files changed, 91 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
>> index d750321..c220646 100644
>> --- a/Documentation/development-process/2.Process
>> +++ b/Documentation/development-process/2.Process
>> @@ -7,20 +7,96 @@ 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.
>>
>> +2.0:SUMMARY
>> +
>> +This section provides a brief summary of the kernel release rules.
>> +
>> +2.0.0: 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.
>> +
>> +2.0.1: MERGE WINDOW
>> +
>> +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. The merge window closes at the first
>> +rc-series 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.
>> +
>> +2.0.2: RC-SERIES RULES
>> +
>> +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
>> + - it must fix a reported security hole
>> + - it must fix a reported oops/kernel hang
>
> - it must fix a bug.
Well that's for certain, but there is a difference between a general
notion of a bug and the type of bug fixes that should go in during the
rc-series. This documentation patch highlights the difference.
> I do not think the 'reported' requirement is there in -rc,
Well if its not reported how else would you find out about it during
the rc-series? And if its something easily triggerable that should
have been fixed earlier, not late in the rc-series.
> and yes,
> compile-fixes etc are welcome.
Sure, but what are these doing so late in the rc-series?
> Non-intrusive bugfixes too, afaict.
It really depends on what you mean but generally no, and this is why I
think this clarification is important.
Luis
On Fri, Jun 19, 2009 at 10:10 AM, Luis R.
Rodriguez<[email protected]> wrote:
> On Fri, Jun 19, 2009 at 8:00 AM, Pavel Machek<[email protected]> wrote:
>> On Tue 2009-06-16 11:17:05, Luis R. Rodriguez wrote:
>>> On Tue, Jun 16, 2009 at 02:34:01AM -0700, Jouni Malinen wrote:
>>> > On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis R. Rodriguez wrote:
>>> >
>>> > > +2.0.2: RC-SERIES RULES
>>> > > +
>>> > > +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
>>> >
>>> >
>>> > s/if/it/ twice..
>>>
>>> Thanks, fixed.
>>>
>>> > Is there a good reason for documenting different rules for rc-series and
>>> > -stable releases? These three rules look stricter than the ones
>>> > described in stable_kernel_rules.txt:
>>> >
>>> > ?- It must fix a problem that causes a build error (but not for things
>>> > ? ?marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>>> > ? ?security issue, or some "oh, that's not good" issue. ?In short, something
>>> > ? ?critical.
>>>
>>> The rc-series rules this patch adds are a summary, so they do indeed appear to be
>>> stricter but I do think new vendor/device ids should be welcomed as well AFAICT,
>>> for instance.
>>>
>>> What may be best is to merge these two somehow and refer to the common rules for
>>> both and try to differentiate between them in their respective documentation
>>> section.
>>>
>>> But I also think good judgement can be applied, good judgement being defined as
>>> that of a subsystem maintainer, which allows us to simply tell developers to
>>> focus on development and send patches up and the respective maintainer routes
>>> the fixes accordingly.
>>>
>>> The spirit of writig this summary is to be clear that rules do exist and that
>>> we cannot simply suggest to read stable_kernel_rules.txt as there are items there
>>> which do not apply.
>>>
>>> Reason for trying to add more documentation for this is today there are a lot
>>> companies are working upstream and a better sense of what can get into specific
>>> kernel releases becomes more important and you also have more responsible
>>> developers looking out to ensure their fixes get propagated to the right trees.
>>> So leaving some of these things undocumented, implied or in the dark can turn
>>> out to not be as healthy and IMHO is what lead to the original issue from which
>>> I extracted information to create this summary.
>>>
>>> > For example, a fix for data corruption that users can hit relatively
>>> > easily sounds like a good example of something that should really be
>>> > accepted during the rc-phase even if it is not really a regression or
>>> > does not cause a kernel oops/hang.
>>>
>>> Agreed.
>>>
>>> > "oh, that's not good" issue is somewhat more difficult to comment on,
>>> > but I would expect that there could be some critical issues that really
>>> > would benefit from an exception. What exactly would qualify is something
>>> > that may be not be easily described in a sentence or two, though.
>>> >
>>> >
>>> > The main problem I see with having a very hard line on not allowing
>>> > critical fixes (however that would be defined) during the rc-phase is
>>> > that it will take quite a long time to get the fix eventually out. As an
>>> > example, a driver could have a bug that prevents it from working with
>>> > certain subset of devices, but this is noticed only couple of kernel
>>> > releases after the initial driver merge (e.g., for hardware that was not
>>> > yet available for end users at the time the driver was initially
>>> > submitted).
>>>
>>> I believe it makes sense to send fixes for new hardware on an old
>>> driver if it is known the fix cannot regress as it does not affect older
>>> hardware.
>>>
>>> > In other words, the issue would not be a regression, not a
>>> > security hole, and not an oops/kernel hang. However, it could make the
>>> > driver unusable to large number of users (once the affected hardware
>>> > model becomes available; say in a new laptop).
>>>
>>> Agreed. But I think that would fall under the new driver category.
>>>
>>> > If an issue is fixed just before a start of the next merge window the
>>> > patch may not have had enough time to go through the maintainers and end
>>> > up in linux-2.6.git in time before the merge window closes. If it
>>> > weren't now allowed in during the rc-phase, it may not go into a stable
>>> > release either (assuming the rc/stable rules are more or less the same)
>>> > and we would be looking something like five month time until the fix
>>> > would actually be released in a proper kernel release. Sure,
>>> > users/distros could take in some additional patches to fix issues they
>>> > care about, but worst case scenarios of close to half a year to fix an
>>> > issue in a kernel release does not sound quite ideal.
>>>
>>> Agreed. In the end it seems to come down to the specifics of the patch and
>>> only the maintainer can really be a good judge of whether it should go in
>>> or not. Of course properly documenting each patch helps, and I believe that
>>> in itself may be good enough to address the grey areas.
>>>
>>> Here's a new patch with the fix you noted. Also added a little stub about
>>> maintainers judgement, etc.
>>>
>>> From: Luis R. Rodriguez <[email protected]>
>>> 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
>>> Documentation/development-process/.
>>>
>>> Also add the number of days it has taken between releases,
>>> and provide the average for the last 10 releases: 86.0 days.
>>>
>>> [1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2
>>> [2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2
>>>
>>> Signed-off-by: Luis R. Rodriguez <[email protected]>
>>> ---
>>> ?Documentation/development-process/2.Process | ? 96 ++++++++++++++++++++++++---
>>> ?Documentation/stable_kernel_rules.txt ? ? ? | ? ?5 ++
>>> ?2 files changed, 91 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
>>> index d750321..c220646 100644
>>> --- a/Documentation/development-process/2.Process
>>> +++ b/Documentation/development-process/2.Process
>>> @@ -7,20 +7,96 @@ 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.
>>>
>>> +2.0:SUMMARY
>>> +
>>> +This section provides a brief summary of the kernel release rules.
>>> +
>>> +2.0.0: 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.
>>> +
>>> +2.0.1: MERGE WINDOW
>>> +
>>> +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. The merge window closes at the first
>>> +rc-series 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.
>>> +
>>> +2.0.2: RC-SERIES RULES
>>> +
>>> +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
>>> + - it must fix a reported security hole
>>> + - it must fix a reported oops/kernel hang
>>
>> - it must fix a bug.
>
> Well that's for certain, but there is a difference between a general
> notion of a bug and the type of bug fixes that should go in during the
> rc-series. This documentation patch highlights the difference.
>
>> I do not think the 'reported' requirement is there in -rc,
>
> Well if its not reported how else would you find out about it during
> the rc-series? And if its something easily triggerable that should
> have been fixed earlier, not late in the rc-series.
>
>> and yes,
>> compile-fixes etc are welcome.
>
> Sure, but what are these doing so late in the rc-series?
>
>> Non-intrusive bugfixes too, afaict.
>
> It really depends on what you mean but generally no, and this is why I
> think this clarification is important.
>
> ?Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
well, this answers my question about merge window
times and, what types of patches belong where.
--
Justin P. Mattock
> >> +2.0.2: RC-SERIES RULES
> >> +
> >> +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
> >> + - it must fix a reported security hole
> >> + - it must fix a reported oops/kernel hang
> >
> > - it must fix a bug.
>
> Well that's for certain, but there is a difference between a general
> notion of a bug and the type of bug fixes that should go in during the
> rc-series. This documentation patch highlights the difference.
Yes, and I'm trying to tell you that this documentation patch is
wrong.
Non-intrusive bugfixes _are_ welcome after -rc1.
> > I do not think the 'reported' requirement is there in -rc,
>
> Well if its not reported how else would you find out about it during
> the rc-series? And if its something easily triggerable that should
> have been fixed earlier, not late in the rc-series.
'reported' means 'someone is hitting that bug' in that context. If you
do code inspection on drivers/foo/bar.c and find that it will hang on
may 13, 2017; then that's a bug but not "reported" one -- users are
not hitting it. Such bug may be uninteresting for -stable, but would
probably be ok for -rc.
> > and yes,
> > compile-fixes etc are welcome.
>
> Sure, but what are these doing so late in the rc-series?
Bugs happen :-).
> > Non-intrusive bugfixes too, afaict.
>
> It really depends on what you mean but generally no, and this is why I
> think this clarification is important.
I believe you are wrong.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek <[email protected]> writes:
> Non-intrusive bugfixes _are_ welcome after -rc1.
I'm under impression that the merge window is for new features, and past
rc1 only fixes are accepted. It may be different past maybe rc6, and
obviously the fixes must be sane enough (even in merge window).
Do they have to fix a bug? I don't know, I guess they can also fix "an
issue" :-)
--
Krzysztof Halasa
On Fri, Jun 19, 2009 at 3:19 PM, Pavel Machek<[email protected]> wrote:
>
>> >> +2.0.2: RC-SERIES RULES
>> >> +
>> >> +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
>> >> + - it must fix a reported security hole
>> >> + - it must fix a reported oops/kernel hang
>> >
>> > - it must fix a bug.
>>
>> Well that's for certain, but there is a difference between a general
>> notion of a bug and the type of bug fixes that should go in during the
>> rc-series. This documentation patch highlights the difference.
>
> Yes, and I'm trying to tell you that this documentation patch is
> wrong.
This mean you might be able to help correct this.
> Non-intrusive bugfixes _are_ welcome after -rc1.
That's great news to me.
I think it would really help to get a clarification on what is meant
by "non-intrusive bugfixes" though. Can you elaborate on that?
>> > Non-intrusive bugfixes too, afaict.
>>
>> It really depends on what you mean but generally no, and this is why I
>> think this clarification is important.
>
> I believe you are wrong.
I was actually hoping I would be. But I'd like some confirmation that I am.
For example, based on your feedback we have a series of fixes we'd
like to try to get merged for 2.6.31-rc2 for ath9k. I have been under
the impression that since those fixes do not meet the criteria
clarified by my original patch on documentation for the rc-series that
they would not get merged and our only option to get users to get
these patches is to wait for 2.6.32 or use some sort of bleeding edge
backport package. We try hard to get out our patches in time prior to
the merge window but sometimes some patches don't manage hit that
timeline so if you tell me we can certainly send "non-intrusive bug
fixes" post rc1 then that is what we will try to do. I just do not
want to get bitch slapped about it when we do.
Luis
On Sat, 20 Jun 2009, Pavel Machek wrote:
>
> Non-intrusive bugfixes _are_ welcome after -rc1.
After -rc1, yes.
After something like -rc5? No.
They had better be _really_ important things, and _really_ obvious and
non-intrusive. Not just "any bug".
Linus
Hello everybody,
I had a question regarding the new netlink interface in the kernels I guess since 2.6.24 and forward.
It looks like the entire netlink interface has changed since that kernel version.
Before the change the netlink function prototype used by drivers is :
void netlinkInput(struct sock *sk, int len)
but this has now changed to :
void netlinkInput(struct sk_buff * skb).
A problem that I am having in my driver is when I receive an skb from my application by the call to sendmsg, I get the packet as an skb in my driver.
Now once I send out the packet and when its time to free the skb, I call dev_kfree_skb_any(skb).
However, this code seems to crash in the freeing of this skb. Is there something wrong that I am doing in the feeing of this skb. Can it not be freed at this point?
Any thoughts?
Thank you.
Vinay
On Fri, Jun 19, 2009 at 3:56 PM, Linus
Torvalds<[email protected]> wrote:
>
>
> On Sat, 20 Jun 2009, Pavel Machek wrote:
>>
>> Non-intrusive bugfixes _are_ welcome after -rc1.
>
> After -rc1, yes.
>
> After something like -rc5? No.
>
> They had better be _really_ important things, and _really_ obvious and
> non-intrusive. Not just "any bug".
For the sake of documentation and to help developers better understand
this it would be nice if we could be a little more clear here. I can
think of patches which may not be obvious but yet very important, for
example. Can we simply document that the patches must be important,
non-intrusive, and must have a very clear commit log entry of what it
is fixing. Judgment for the degree of importance of the patch can be
left up to the subsystem maintainer.
Is it reasonable to document this as I describe above?
Luis
> > Non-intrusive bugfixes _are_ welcome after -rc1.
>
> That's great news to me.
>
> I think it would really help to get a clarification on what is meant
> by "non-intrusive bugfixes" though. Can you elaborate on that?
Typo fix in printk() is non-intrusive, 'apply this series' is
borderline; if issue is bad enough it may be ok. I guess only Linus
can clarify more.
> >> > Non-intrusive bugfixes too, afaict.
> >>
> >> It really depends on what you mean but generally no, and this is why I
> >> think this clarification is important.
> >
> > I believe you are wrong.
>
> I was actually hoping I would be. But I'd like some confirmation that I am.
>
> For example, based on your feedback we have a series of fixes we'd
> like to try to get merged for 2.6.31-rc2 for ath9k. I have been under
> the impression that since those fixes do not meet the criteria
> clarified by my original patch on documentation for the rc-series that
> they would not get merged and our only option to get users to get
> these patches is to wait for 2.6.32 or use some sort of bleeding edge
> backport package. We try hard to get out our patches in time prior
I believe 'no git merges after rc1' is one of rules.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html