From: Theodore Ts'o <tytso@mit.edu>
To: Li Zefan <lizefan@huawei.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>,
lizf.kern@gmail.com, ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] stable issues
Date: Mon, 5 May 2014 09:41:26 -0400 [thread overview]
Message-ID: <20140505134126.GA22287@thunk.org> (raw)
In-Reply-To: <5366FBDB.7090705@huawei.com>
On Mon, May 05, 2014 at 10:47:55AM +0800, Li Zefan wrote:
>
> Yeah, but we can't expect other maintainers to do this. As Greg has been
> emphasizing, we'd want to add as little burden as possible for subsystem
> maintainers. With this in mind, focusing on fewer LTS kernels might make
> sense?
An LTS kernel becomes important when distributions or manufacturers
need to depend on one for their stable/enterprise distribution or for
some product release. The problem comes when a stable kernel such as
3.10 gets declared, but some feature which is badly needed doesn't
make it into 3.11, say, or at the time when 3.10 gets declared, some
internal team had already decided to use 3.11.
So what might help is if companies or distributions who need a LTS
kernel were willing to disclose that fact ahead of time, and see if
they can find like-minded associates who also might need a LTS kernel
around about the same time. Obviously if a company is willing to
dedicate resources to maintaining the LTS kernel they should have a
bit more say about which LTS kernel they would be willing to support.
I am aware of companies or distributions which are using 3.10, 3.11,
and 3.12 (yes, all three!) for different long-term product/production
kernels. The company that used 3.11 didn't talk to anyone externally
before selecting 3.11, and so it's only right that this company live
with the consequences of that particular engineering decision. But
yeah, with a bit of communication, I suspect it could have resulted in
a bit less work all around.
The challenge is that companies generally need to be able to make that
decision at least 3-6 months ahead of time for planning purposes, and
this requires that companies be willing to actually communicate their
stablization plans externally ahead of time. Which, unfortuantely,
may or may not always be practical.
And of course, depending on how many patches get integrated into said
"enterprise" kernel, it might end up being very far from the official
upstream stable kernel, so it might or might not matter in any case.
Cheers,
- Ted
next prev parent reply other threads:[~2014-05-05 13:41 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-04 11:19 Li Zefan
2014-05-04 12:04 ` Guenter Roeck
2014-05-04 12:54 ` Josh Boyer
2014-05-04 14:26 ` Guenter Roeck
2014-05-05 0:37 ` Josh Boyer
2014-05-05 3:09 ` Li Zefan
2014-05-05 3:47 ` Guenter Roeck
2014-05-05 11:31 ` Jason Cooper
2014-05-05 13:40 ` Guenter Roeck
2014-05-05 6:10 ` Michal Simek
2014-05-05 2:47 ` Li Zefan
2014-05-05 13:41 ` Theodore Ts'o [this message]
2014-05-05 15:23 ` Takashi Iwai
2014-05-05 15:39 ` Jan Kara
2014-05-05 16:02 ` Takashi Iwai
2014-05-05 16:07 ` Jason Cooper
2014-05-05 16:17 ` Takashi Iwai
2014-05-05 22:33 ` Greg KH
2014-05-06 3:20 ` Steven Rostedt
2014-05-06 4:04 ` Guenter Roeck
2014-05-06 10:49 ` Steven Rostedt
2014-05-05 3:22 ` Greg KH
2014-05-04 15:35 ` Ben Hutchings
2014-05-04 15:45 ` Guenter Roeck
2014-05-05 3:00 ` Li Zefan
2014-05-05 1:03 ` Olof Johansson
2014-05-07 2:49 ` Masami Hiramatsu
2014-05-07 2:58 ` Davidlohr Bueso
2014-05-07 8:27 ` Masami Hiramatsu
2014-05-07 8:39 ` Matt Fleming
2014-05-07 11:45 ` Masami Hiramatsu
2014-05-07 12:45 ` Daniel Vetter
2014-05-08 3:20 ` Masami Hiramatsu
2014-05-09 12:32 ` Daniel Vetter
2014-05-12 6:55 ` Masami Hiramatsu
2014-05-13 20:36 ` Steven Rostedt
2014-05-13 20:40 ` Davidlohr Bueso
2014-05-14 1:30 ` Masami Hiramatsu
2014-05-07 18:40 ` Davidlohr Bueso
2014-05-07 9:06 ` Dan Carpenter
2014-05-07 14:15 ` Jan Kara
2014-05-08 3:38 ` Li Zefan
2014-05-08 9:41 ` Jan Kara
2014-05-08 20:35 ` Andy Lutomirski
2014-05-09 4:11 ` Greg KH
2014-05-09 5:33 ` Masami Hiramatsu
2014-05-09 5:41 ` Greg KH
2014-05-07 3:05 ` Li Zefan
2014-05-07 3:31 ` Masami Hiramatsu
2014-05-07 7:20 ` Laurent Pinchart
2014-05-13 20:46 ` Steven Rostedt
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=20140505134126.GA22287@thunk.org \
--to=tytso@mit.edu \
--cc=jwboyer@fedoraproject.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=lizefan@huawei.com \
--cc=lizf.kern@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox