From: Sasha Levin <sasha.levin@oracle.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Issues with stable process
Date: Sun, 12 Jul 2015 09:32:11 -0400 [thread overview]
Message-ID: <55A26C5B.8060007@oracle.com> (raw)
In-Reply-To: <CAMuHMdUK+LZrp9QxPS0wSJzFZVAr_cihxJnFJybo5nb7U_t7xg@mail.gmail.com>
On 07/12/2015 06:02 AM, Geert Uytterhoeven wrote:
> On Sat, Jul 11, 2015 at 6:12 PM, Sasha Levin <sasha.levin@oracle.com> wrote:
>> 1. During the RC cycles bug fixes tend to get sent to Linus without going through
>> linux-next. This is very risky, but it seems to work(?). The problem is that Linus
>> doesn't restrict those fixes to bugs that were introduced in the current merge window
>> but takes anything that is labelled as a "fix".
>>
>> The result is that there is a significant amount of mostly untested RC patches
>> trickling down into stable trees, causing breakage for folks who assume that they
>> are running a tested kernel but end up with commits that haven't even been in
>> linux-next for more than a few days.
>>
>> Since for RC kernel it's expected to see issues, and it's easy to correct, this is
>> less than a problem, but consider this flow for stable:
>>
>> * 4.0: bug "A" introduced.
>> * 4.2-rc1: bug "A" fixed, but fix unknowingly introduced bug "B".
>
> And the fix for "A" was not in -next?
> It will be the next day, though.
It will, but there's a huge difference between being in -next for a day or a month before
getting merged in.
Usually the amount of time it spends in -next equals to the amount of time it takes to
trickle from the author through the maintainer chain all the way to Linus.
>> * 4.1.1: ships with fix for "A", and new bug "B".
>
> For serious bugs, the fix may indeed be applied Really Quick.
Right.
>> * Stable user machines suffer from breakage.
>> * 4.2-rc7: bug "B" fixed.
>> * Stable users still suffer until the next kernel release.
>>
>> So while it was quickly fixed for RC, this seriously affects stable.
>
> I wouldn't say "quickly": there's quite some time period (6 weeks) between
> -rc1 and -rc7.
So it would be the same scenario if I wrote there "-rc1..-rc2". LTS kernel users
tend to upgrade their kernel less often than those 6 weeks anyhow.
> If the fix for "B" has a proper "Fixes:" tag, I guess it will be applied to
> the next -stable soon. Hence make sure to always provide a "Fixes:" tag when
> fixing bugs.
True. I'm not saying it wouldn't be fixed in the next stable release, I'm saying
that we're sending untested patches all the way to users who expect the most stable
kernel.
> 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?
Thanks,
Sasha
next prev parent reply other threads:[~2015-07-12 13:32 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 [this message]
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
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=55A26C5B.8060007@oracle.com \
--to=sasha.levin@oracle.com \
--cc=geert@linux-m68k.org \
--cc=ksummit-discuss@lists.linuxfoundation.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.