From: Sasha Levin <sasha.levin@oracle.com>
To: NeilBrown <neilb@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"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 22:09:50 -0400 [thread overview]
Message-ID: <55A5C0EE.3060803@oracle.com> (raw)
In-Reply-To: <20150715114946.481f154d@noble>
On 07/14/2015 09:49 PM, NeilBrown wrote:
> On Tue, 14 Jul 2015 15:30:37 -0400 Sasha Levin <sasha.levin@oracle.com>
> wrote:
>
>> On 07/14/2015 12:02 PM, Steven Rostedt wrote:
>>> On Tue, 14 Jul 2015 11:53:24 -0400
>>> Sasha Levin <sasha.levin@oracle.com> wrote:
>>>
>>>
>>>>> The point I'm trying to make is that a bad patch in Linus' tree has a wider
>>>>> ripple effect than what it were in the past, while Linus might consider a bad
>>>>> patch in one of the -rc releases something minor since "no one should be using
>>>>> it for production" it really isn't the case any more, those patches can and
>>>>> will end up with the folks who don't want to have them.
>>> I have to ask, why?
>>>
>>> Just because a stable tag is on a patch it automatically gets pulled
>>> into stable? What about waiting a while before pulling in those
>>> patches? Wait till -rc2 is out before pulling in any patches marked for
>>> stable in -rc1. Then wait for -rc3 to pull in the patches that were
>>> added in -rc2. But don't pull in any patches that has a "Fixes" to it
>>> in the next -rc release.
>>>
>>> That is, when -rc2 is released, only pull in the patches marked for
>>> stable in -rc1 if there were no Fixes tags for them in -rc2. And so on.
>>>
>>> Again, just placing stuff in -next isn't going to solve this. It may
>>> help, but you will still have fixes that breaks things when they get
>>> into Linus's tree no matter how long they were in -next. This is simply
>>> because Linus's tree has a wider audience. But hopefully, the next
>>> release candidate will have the fixes for anything that breaks in the
>>> previous release candidate.
>>
>> I agree that this would be enough for -stable.
>>
>> But wouldn't you agree that the policy of not passing patches in -rc cycles
>> through -next at all is incorrect?
>>
>> I'm fine with not having a minimal time it must live in -next, but I really
>> think that it should be in -next at some point.
>
> What exactly is the value of sitting in -next for a while.
> -next was originally to catch integration issues, and a "simple" bug
> fix shouldn't have those.
>
> 0-day runs of -next, but then it runs on lots of other trees too. So
> if you want 0-day coverage (which I do), then the rule doesn't have to
> "in -next" but only "in a 0-day tree".
>
> So what, specifically, is the value that a bug-fix patch gets from
> -next that it cannot get elsewhere?
Right, -next was originally there to catch integration but this is no longer
the case: between Fengguang's tests which go beyond just building, kernelci.org
which also does boot tests on multiple platforms, and various people (myself
included) who do various testing on -next, a good chunk of non-integration
bugs is getting caught in -next before it even reaches Linus.
We could keep closing our eyes and claiming that -next is there only to deal
with the likes of merge conflicts, but reality is different and it's actually
better than what you're suggesting the intention of -next is.
Thanks,
Sasha
next prev parent reply other threads:[~2015-07-15 2:09 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 [this message]
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=55A5C0EE.3060803@oracle.com \
--to=sasha.levin@oracle.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=neilb@suse.com \
--cc=torvalds@linux-foundation.org \
/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.