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 [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 [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 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.