From: "Levin, Alexander" <alexander.levin@verizon.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: "ltsi-dev@lists.linuxfoundation.org"
<ltsi-dev@lists.linuxfoundation.org>,
Mark Brown <broonie@linaro.org>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [Stable kernel] feature backporting collaboration
Date: Fri, 2 Sep 2016 15:31:03 -0400 [thread overview]
Message-ID: <20160902193103.GD6323@sasha-lappy> (raw)
In-Reply-To: <20160902134711.movdpffcdcsx6kzv@thunk.org>
Hi Ted,
On Fri, Sep 02, 2016 at 09:47:11AM -0400, Theodore Ts'o wrote:
> Or for that matter, why not simply going to the latest mainline
> kernel. Since the SOC vendors aren't taking updates from the LTS
> kernel anyway, if the LTS kernel exists only as a patch repository
> where people can look for security fixes and bug fixes (sometimes
> after the upstream maintainer has to point out it's in the LTS
> kernel), if they take, say, 4.7, in the future they might need to take
> a look at 4.8.x, 4.9.x, etc., until the next LTS kernel is declared.
> So that means that an SOC vendor or a downstream product vendors might
> have to look at 3 or 4 patch releases instead of one. Is that really
> that hard?
I agree with everything you said besides this last paragraph, and it's
our fault.
In theory, the flow of commits that need to go into the stable tree should
have uniform distribution: Linus takes fixes at any point in time, so unlike
new features that come in only during the merge window fixes should be
constantly flowing in.
However, this is not the case; looking at LTS kernel releases during merge
windows we can see that the volume of commits that go into LTS kernel is much
higher than during release candidate cycles. Why? people still hold off on
sending fixes for a variety of reasons, which isn't the way it's supposed to
happen.
As a result, I'd never want to use mainline for production. The first kernel
I'd consider is a stable kernel that has taken in everything that was sent
during a merge window of the next release.
--
Thanks,
Sasha
next prev parent reply other threads:[~2016-09-02 19:31 UTC|newest]
Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 2:01 Alex Shi
2016-09-02 1:25 ` Levin, Alexander
2016-09-02 2:43 ` Stephen Hemminger
2016-09-02 9:59 ` Mark Brown
2016-09-02 9:54 ` Mark Brown
2016-09-02 10:16 ` [Ksummit-discuss] [LTSI-dev] " Geert Uytterhoeven
2016-09-02 14:42 ` [Ksummit-discuss] " James Bottomley
2016-09-02 14:55 ` Rik van Riel
2016-09-02 15:04 ` James Bottomley
2016-09-02 15:39 ` Rik van Riel
2016-09-02 17:06 ` Bird, Timothy
2016-09-05 1:45 ` NeilBrown
2016-09-05 11:04 ` Mark Brown
2016-09-05 22:44 ` NeilBrown
2016-09-06 0:57 ` Mark Brown
2016-09-06 5:41 ` NeilBrown
2016-09-08 18:33 ` [Ksummit-discuss] [LTSI-dev] " Bird, Timothy
2016-09-08 22:38 ` NeilBrown
2016-09-09 11:01 ` Mark Brown
2016-09-09 22:17 ` NeilBrown
2016-09-12 17:37 ` Mark Brown
2016-09-13 7:46 ` NeilBrown
2016-09-13 17:53 ` Mark Brown
2016-09-02 18:21 ` [Ksummit-discuss] " Olof Johansson
2016-09-02 23:35 ` Mark Brown
2016-09-03 5:29 ` Guenter Roeck
2016-09-03 10:40 ` Mark Brown
2016-09-04 0:10 ` Theodore Ts'o
2016-09-04 8:34 ` gregkh
2016-09-04 22:58 ` Amit Kucheria
2016-09-04 23:51 ` Theodore Ts'o
2016-09-05 12:58 ` Mark Brown
2016-09-05 11:11 ` Mark Brown
2016-09-05 14:03 ` Theodore Ts'o
2016-09-05 14:22 ` Laurent Pinchart
2016-09-06 0:35 ` Mark Brown
2016-09-06 15:30 ` James Bottomley
2016-09-06 19:44 ` gregkh
2016-09-06 22:20 ` Mark Brown
2016-09-06 22:34 ` James Bottomley
2016-09-08 18:55 ` Bird, Timothy
2016-09-08 19:19 ` gregkh
2016-09-09 10:45 ` Mark Brown
2016-09-09 11:03 ` gregkh
2016-09-09 11:48 ` Mark Brown
2016-09-06 23:23 ` Mark Brown
2016-09-06 13:34 ` Catalin Marinas
2016-09-06 16:24 ` Bartlomiej Zolnierkiewicz
2016-09-06 16:25 ` Guenter Roeck
2016-09-06 22:39 ` Mark Brown
2016-09-07 8:33 ` Jan Kara
2016-09-07 8:41 ` Jiri Kosina
2016-09-07 18:44 ` Mark Brown
2016-09-08 17:06 ` Frank Rowand
2016-09-09 10:32 ` Mark Brown
2016-09-09 15:21 ` Alex Shi
2016-09-12 15:34 ` Christoph Hellwig
2016-09-06 16:46 ` Olof Johansson
2016-09-08 8:34 ` Linus Walleij
2016-09-08 8:55 ` Vinod Koul
2016-09-09 14:32 ` Rob Herring
2016-09-09 14:23 ` Rob Herring
[not found] ` <2181684.5VzIQ6DWv4@amdc1976>
2016-09-07 9:32 ` Catalin Marinas
2016-09-07 13:07 ` Bartlomiej Zolnierkiewicz
2016-09-07 18:49 ` Mark Brown
2016-09-09 15:06 ` Alex Shi
2016-09-02 23:29 ` Mark Brown
2016-09-02 19:16 ` Levin, Alexander
2016-09-03 0:05 ` Mark Brown
2016-09-05 9:28 ` Laurent Pinchart
2016-09-21 6:58 ` Alex Shi
2016-09-21 9:23 ` gregkh
2016-09-21 14:52 ` Alex Shi
2016-09-21 15:28 ` gregkh
2016-09-21 18:50 ` Mark Brown
2016-09-22 3:15 ` Alex Shi
2016-09-21 18:22 ` Mark Brown
2016-09-21 18:54 ` Linus Walleij
2016-09-21 19:52 ` Theodore Ts'o
2016-09-22 0:43 ` Mark Brown
2016-09-22 5:20 ` gregkh
2016-09-22 12:56 ` Laurent Pinchart
2016-09-22 16:22 ` Mark Brown
2016-09-22 22:14 ` Theodore Ts'o
2016-09-23 12:28 ` Laurent Pinchart
2016-09-23 13:27 ` [Ksummit-discuss] [LTSI-dev] " Alex Shi
2016-09-23 13:40 ` Laurent Pinchart
2016-09-23 14:40 ` [Ksummit-discuss] " Mark Brown
2016-09-21 13:56 ` Theodore Ts'o
2016-09-21 15:23 ` Alex Shi
2016-09-21 15:33 ` gregkh
2016-09-21 19:16 ` Mark Brown
2016-09-02 13:47 ` Theodore Ts'o
2016-09-02 19:31 ` Levin, Alexander [this message]
2016-09-02 19:42 ` gregkh
2016-09-02 20:06 ` Levin, Alexander
2016-09-03 2:04 ` Mark Brown
2016-09-06 7:20 ` [Ksummit-discuss] [LTSI-dev] " Tsugikazu Shibata
2016-09-10 12:00 ` Theodore Ts'o
2016-09-12 16:27 ` Mark Brown
2016-09-12 17:14 ` Greg KH
2016-09-12 23:45 ` Mark Brown
2016-09-13 3:14 ` Theodore Ts'o
2016-09-13 10:14 ` Mark Brown
2016-09-13 13:19 ` Levin, Alexander
2016-09-13 6:19 ` Greg KH
2016-09-13 10:38 ` Mark Brown
2016-09-13 12:09 ` Greg KH
2016-09-13 12:20 ` Josh Boyer
2016-09-13 13:12 ` Greg KH
2016-09-13 16:23 ` Bird, Timothy
2016-09-13 19:02 ` Mark Brown
2016-09-14 14:47 ` Alex Shi
2016-09-20 5:15 ` Tsugikazu Shibata
2016-09-21 8:46 ` Alex Shi
2016-09-13 12:25 ` Geert Uytterhoeven
2016-09-13 19:21 ` Mark Brown
2016-09-14 1:49 ` Greg KH
2016-09-14 3:00 ` Guenter Roeck
2016-09-12 4:12 ` Alex Shi
2016-09-12 16:09 ` Masami Hiramatsu
2016-09-13 2:39 ` Alex Shi
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=20160902193103.GD6323@sasha-lappy \
--to=alexander.levin@verizon.com \
--cc=broonie@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=ltsi-dev@lists.linuxfoundation.org \
--cc=tytso@mit.edu \
/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