Date:	Tue, 16 Jun 2009 12:34:01 +0300
From:	Jouni Malinen <j@...fi>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
Cc:	Greg KH <greg@...ah.com>,
	Luis Rodriguez <Luis.Rodriguez@...eros.com>,
	"corbet@....net" <corbet@....net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"tshibata@...jp.nec.com" <tshibata@...jp.nec.com>,
	"mcgrof@...il.com" <mcgrof@...il.com>
Subject: Re: [RFC] Documentation: add documentation for rc-series and merge
	window

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists