[Ksummit-discuss] [CORE TOPIC] stable issues

Greg KH greg at kroah.com
Mon May 5 22:33:24 UTC 2014

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.


greg k-h

More information about the Ksummit-discuss mailing list