From: Steven Rostedt <rostedt@goodmis.org>
To: James Bottomley <James.Bottomley@HansenPartnership.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: Tue, 14 Jul 2015 09:29:55 -0400 [thread overview]
Message-ID: <20150714092955.2d28984b@gandalf.local.home> (raw)
In-Reply-To: <1436871795.2445.8.camel@HansenPartnership.com>
On Tue, 14 Jul 2015 12:03:15 +0100
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> No harm comes to us from running regression fixes into -next and thus in
> the 0day tests because they eventually get into the correct kernel and
> the benefit is that bogus fixes may be picked up by the tests. Why
> would we not incubate for a while in -next when there's no down side and
> plenty of upside?
Mark Brown mentioned the down side. Depending on what the bug is,
especially if it breaks Linus's build, or causes some other major
breakage, to wait in next means that Linus's tree (that everyone is
based on) will be broken for that long too. Which could stop other
types of testing of Linus's tree.
In fact, I have a series of tests I run before pushing any patch to
Linus. If my tests break because of other breakage in Linus's tree, I
have to stop what I'm doing and find those bugs before I can proceed.
With v4.2-rc1, I found 3 bugs that I had to fix or find workarounds
before I could push my fixes to Linus.
I've been trying to get time to test against -next before the merge
window opens, because my tests usually discover these there. But I
don't always have time to do so.
-- Steve
next prev parent reply other threads:[~2015-07-14 15:56 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 [this message]
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=20150714092955.2d28984b@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--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.