ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Josh Boyer <jwboyer@fedoraproject.org>,
	ksummit-discuss@lists.linuxfoundation.org, lizf.kern@gmail.com
Subject: Re: [Ksummit-discuss] [CORE TOPIC] stable issues
Date: Mon, 5 May 2014 15:33:24 -0700	[thread overview]
Message-ID: <20140505223324.GA5298@kroah.com> (raw)
In-Reply-To: <20140505134126.GA22287@thunk.org>

On Mon, May 05, 2014 at 09:41:26AM -0400, Theodore Ts'o wrote:
> 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 spend a lot of time talking to a lot of different companies about what
the next LTS kernel will be.  And almost all of them are willing to give
me this information, so this isn't an issue.

The problem is, I can't please all of the people all of the time.  When
picking just one kernel a year, someone's schedule is not going to
align, and so they have to "go it alone".  Which is just part of the
"game" in doing releases, everyone knows this.

And as for announcing it ahead of time, I'm never going to do that
again, the aftermath was horrid of people putting stuff that shouldn't
be there.  Heck, when people know about what the enterprise kernels are
going to be, they throw stuff into upstream "early", so it's a
well-known pattern and issue.

thanks,

greg k-h

  parent reply	other threads:[~2014-05-05 22:30 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
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 [this message]
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=20140505223324.GA5298@kroah.com \
    --to=greg@kroah.com \
    --cc=jwboyer@fedoraproject.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=lizf.kern@gmail.com \
    --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