Re: [RFC] Documentation: add documentation for rc-series and merge window

On Fri, Jun 19, 2009 at 10:10 AM, Luis R.
Rodriguez<lrodriguez@xxxxxxxxxxx> wrote:
On Fri, Jun 19, 2009 at 8:00 AM, Pavel Machek<pavel@xxxxxx> 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 <lrodriguez@xxxxxxxxxxx>
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 <lrodriguez@xxxxxxxxxxx>
---
 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 majordomo@xxxxxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages