From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: ksummit-discuss@lists.linuxfoundation.org, NeilBrown <neilb@suse.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Issues with stable process
Date: Tue, 14 Jul 2015 00:55:18 +0200 [thread overview]
Message-ID: <2357837.dgQRuM7BY1@vostro.rjw.lan> (raw)
In-Reply-To: <20150713151012.6da5f019@noble>
On Monday, July 13, 2015 03:10:12 PM NeilBrown wrote:
> On Mon, 13 Jul 2015 00:27:52 -0400 Sasha Levin <sasha.levin@oracle.com>
> wrote:
>
> > On 07/12/2015 08:52 PM, NeilBrown wrote:
> > > 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'd actually argue that Linus shouldn't be pulling *anything* that wasn't in
> > -next for 2+ weeks. There's no good excuse to want something pulled immediately
> > as the only benefit Linus's tree provides in that aspect is the wider testing
> > it receives, so it would make sense to weed out more bugs in -next before they
> > get to Linus.
>
> As long as there is a clear 2 week window between a patch being "out
> there for wide testing" and being auto-pulled into a -stable, I would
> see an improvement.
>
> However I'm not at all convinced that being in -next is really "out
> there for wide testing".
Agreed. I'm not even sure about -rcs from Linus for that matter.
Unfortunately, -stable often get's wide testing before anything else.
> Certainly some testing happens in -next, but my understand is that it is
> mainly about integration testing, not burn-in testing.
>
> Isn't the point of the 2-week merge window is that we all stop writing
> more bugs and instead start testing to find each others bugs? You seem
> to want to make the previous two weeks fill that role. I don't think
> that would work.
I guess the idea is to avoid exposing -stable users to commits that
mainline users have not been really exposed to yet.
It really is a matter of what is marked for -stable IMO. Some of those things
should not really carry a "Cc: stable" tag until they've received some wider
testing in the mainline.
> > I think that this is a small mind-shift from thinking about Linus's tree as
> > an integration tree to considering it as mostly bug-free code, and stop
> > merging in risky patches. We already have -next for that.
>
> I certainly do see Linus's tree as mostly bug-free code. Certainly I
> don't submit something until I'm reasonably confident. Unfortunately I
> am sometimes wrong. Usually by rc8 it is a lot closer to bug-free.
> That steady improvement is the whole point. So going from rc8 to
> stable makes lots more sense than going from rc1 to stable.
Agreed.
Thanks,
Rafael
next prev parent reply other threads:[~2015-07-13 22:28 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 16:12 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 [this message]
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
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=2357837.dgQRuM7BY1@vostro.rjw.lan \
--to=rjw@rjwysocki.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox