From: Jan Kara <jack@suse.cz>
To: NeilBrown <neilb@suse.com>
Cc: Sasha Levin <sasha.levin@oracle.com>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Issues with stable process
Date: Mon, 13 Jul 2015 11:22:21 +0200 [thread overview]
Message-ID: <20150713092221.GA8609@quack.suse.cz> (raw)
In-Reply-To: <20150713105210.6e367f4b@noble>
Hello,
On Mon 13-07-15 10:52:10, NeilBrown wrote:
>
> I've been bitten by this a couple of times too. At least two fairly
> serious md bugs *never* got into a release from Linus, but did get into
> -stable and at least one into a vendor kernel.
>
> On Sun, 12 Jul 2015 09:32:11 -0400 Sasha Levin <sasha.levin@oracle.com>
> wrote:
>
>
> > > So it boils down to: "How soon to apply fixes to -stable?", and the trade-off
> > > between applying fixes early, but risking to break something unknown and new,
> > > vs. applying fixes late (after more validation), causing more breakage from a
> > > known issue.
> >
> > That's just one solution, but there are a few more (which is why it's worth discussing
> > it :) ).
> >
> > Consider also:
> >
> > - Aligning the stable release process with the kernel where we'd do a few release
> > candidates for the stable kernel before releasing it.
> >
> > - Tightening what is allowed to go in as -rc patches, requiring some time in -next
> > before it even gets into Linus's hands. Even for "serious" things (does it matter if
> > a fix for a privesc gets in -rc2 or -rc6, beyond that it would be pulled to stable
> > earlier?)
> >
> > - Differentiate the type of patches going into "regular" -stable, and LTS?
> >
>
> My proposal would be to change the default timing.
> Currently patches tagged for 'stable' go into the next -stable release
> after they get into Linus's tree. You can ask for an exception
> (sooner, later, different patch) and Greg (or any other stable
> maintainer) tries to be accommodating. But you have to remember to ask.
>
> I would rather that the default was that patches don't go into -stable
> until they have
> - been in a full release from Linus and
> - been in a Linus's tree for at least 2 weeks.
> (or 1 week times the age of the target in releases.
> So a fix in 4.4 get to 4.3-stable after a week, 4.2-stable
> after 2 weeks etc .... maybe I'm going over-board here).
>
> Many fixes are important but simply aren't that urgent so the two or
> more weeks is no great cost.
I agree with this and it seems as a sensible thing. In the last merge window
I had introduced two regression (:-|) - one in audit and one in ext4.
Neither of these two patches was marked for stable but that doesn't really
make a difference. Now both patches passed a review, testing in maintainer
tree, testing in linux-next for quite a while and only once they went into
Linus' tree people found the regression relatively quickly (couple of days,
definitely less than two weeks). And it's not like maintainers were
mindlessly applying patches or not testing their tree, just they happened
to not hit the bugs. It's the breadth of testing Linus' tree gets which
helps to shake out more subtle bugs. So from that point of view leting the
patch live for some time in Linus' tree before merging it into stable tree
makes sense to me.
One could argue that we should be doing more testing of linux-next but
people tend to develop against Linus' tree rather than linux-next which
also makes Linus' tree natural testing target... So I think that would be
a difficult fight for doubtful gain.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2015-07-13 9:22 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 16:12 [Ksummit-discuss] [CORE TOPIC] Issues with stable process Sasha Levin
2015-07-12 10:02 ` Geert Uytterhoeven
2015-07-12 13:32 ` Sasha Levin
2015-07-13 0:52 ` NeilBrown
2015-07-13 3:32 ` Andy Lutomirski
2015-07-13 4:27 ` Sasha Levin
2015-07-13 5:10 ` NeilBrown
2015-07-13 22:55 ` Rafael J. Wysocki
2015-07-13 18:21 ` Steven Rostedt
2015-07-13 18:51 ` Mark Brown
2015-07-15 14:52 ` Olof Johansson
2015-07-15 15:59 ` Guenter Roeck
2015-07-15 16:03 ` Greg KH
2015-07-15 16:15 ` Sasha Levin
2015-07-15 16:40 ` Greg KH
2015-07-15 19:34 ` Josh Boyer
2015-07-15 21:21 ` Sasha Levin
2015-07-15 22:34 ` Greg KH
2015-07-15 22:40 ` Sasha Levin
2015-07-16 3:36 ` Greg KH
2015-07-17 0:52 ` Rafael J. Wysocki
2015-07-16 9:06 ` Zefan Li
2015-07-16 18:14 ` Olof Johansson
2015-07-14 0:42 ` Sasha Levin
2015-07-14 1:02 ` Steven Rostedt
2015-07-14 2:00 ` Sasha Levin
2015-07-14 2:28 ` Jonathan Corbet
2015-07-14 3:48 ` Stephen Rothwell
2015-07-14 7:14 ` Geert Uytterhoeven
2015-07-14 11:03 ` James Bottomley
2015-07-14 13:29 ` Steven Rostedt
2015-07-14 20:17 ` James Bottomley
2015-07-14 20:45 ` Mark Brown
2015-07-14 22:12 ` Steven Rostedt
2015-07-14 22:36 ` Andy Lutomirski
2015-09-01 8:44 ` Jani Nikula
2015-09-01 20:52 ` Greg KH
2015-09-01 21:00 ` Sasha Levin
2015-09-01 21:08 ` Jiri Kosina
2015-09-01 22:47 ` Sasha Levin
2015-09-02 10:10 ` Luis Henriques
2015-07-16 0:53 ` Rafael J. Wysocki
2015-07-16 11:50 ` Mark Brown
2015-07-14 3:42 ` Stephen Rothwell
2015-07-14 7:03 ` Geert Uytterhoeven
2015-07-14 10:46 ` Mark Brown
2015-07-14 13:57 ` Sasha Levin
2015-07-14 15:25 ` Mark Brown
2015-07-14 15:32 ` Sasha Levin
2015-07-14 15:38 ` Steven Rostedt
2015-07-14 15:53 ` Sasha Levin
2015-07-14 16:02 ` Steven Rostedt
2015-07-14 19:30 ` Sasha Levin
2015-07-14 19:38 ` Steven Rostedt
2015-07-15 1:49 ` NeilBrown
2015-07-15 2:09 ` Sasha Levin
2015-07-15 2:28 ` NeilBrown
2015-07-15 10:13 ` James Bottomley
2015-07-15 23:24 ` NeilBrown
2015-07-16 1:05 ` Andy Lutomirski
2015-07-16 1:43 ` Linus Torvalds
2015-07-16 1:25 ` Steven Rostedt
2015-07-16 9:19 ` James Bottomley
2015-07-16 12:33 ` Jonathan Cameron
2015-08-03 8:32 ` Fengguang Wu
2015-07-14 15:56 ` Mark Brown
2015-07-14 19:01 ` Sasha Levin
2015-07-14 19:18 ` Geert Uytterhoeven
2015-07-14 19:31 ` Sasha Levin
2015-07-15 9:26 ` Jan Kara
2015-07-16 12:53 ` Mark Brown
2015-07-13 9:22 ` Jan Kara [this message]
2015-07-13 20:51 ` Greg KH
2015-07-14 0:51 ` Sasha Levin
2015-07-14 2:46 ` NeilBrown
2015-07-15 19:41 ` Steven Rostedt
2015-07-15 20:14 ` James Bottomley
2015-07-12 15:01 ` Masami Hiramatsu
2015-07-13 10:15 ` Zefan Li
2015-07-13 16:12 ` Sasha Levin
2015-07-14 10:08 ` Zefan Li
2015-07-14 14:00 ` Sasha Levin
2015-07-15 0:01 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150713092221.GA8609@quack.suse.cz \
--to=jack@suse.cz \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=neilb@suse.com \
--cc=sasha.levin@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.