Re: Next LTS release

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 08, 2016 at 02:59:33PM +0200, Mason wrote:
> On 08/06/2016 03:56, Greg KH wrote:
> > On Mon, Jun 06, 2016 at 09:36:47AM +0200, Mason wrote:
> >> Hello,
> >>
> >> I read the kernel summit summary.
> >> https://lwn.net/Articles/662966/
> >>
> >> I was wondering if the 4.4 release set a "precedent" in that the
> >> next few LTS releases going forward would be aimed for early Q1?
> > 
> > Probably.
> 
> Bummer.

Can't please everyone, sorry :)

> >> The reason I'm asking is that my company plans to release an SDK
> >> in Q4, and I was hoping to bundle a recent kernel.
> > 
> > Nothing preventing you from always just advancing your kernel to the
> > latest LTS one when it comes out, right?
> 
> Some customers, once they have something working, they don't want
> to change anything. If I release a v4.4-based SDK, and then such
> a customer comes along, I'll be stuck having to support v4.4 until
> my beard is grey.
> (I was told we are still expected to support several 2.6 kernels.)

You can tell them that they are running insecure kernels that are
trivial to break into, and provide them with the latest kernel release
to resolve that.

In fact, your contracts might require that, given that everyone knows we
are fixing about 10 things every day in newer stable kernels, and 2-3
things every day in very old long-term kernels.

> >> I currently provide 4.4 but most of my port was accepted in later
> >> versions. I was hoping I wouldn't need to backport all that code.
> >>
> >> What do the tea leaves say?
> > 
> > Something in Q1, no idea what number specifically, but if all of your
> > code is already merged upstream, it doesn't really matter what you pick,
> > anything will end up working for you.
> 
> The platform code got merged in 4.5 and 4.6 but I'm still missing
> several important (but non-essential) drivers. Thus 4.4 isn't really
> helpful to me, I'd have to port everything.

Then pick 4.6 and support it and then give them 4.7, and 4.8, and so on.
It's not hard, and everything will still work just fine, that's a
guarantee we made a long time ago and it's worked.

> By the way, looking at the LTS releases, it seems some (older) releases
> are supported longer than others (3.16, 3.12, 3.10, 3.4, 3.2). Is that
> because some are supported by other groups/distros? (IIUC, many Android
> devices run 3.4 and 3.10)

Those 3.4 and 3.10 Android releases are not getting updates, they just
happened to start out with the LTS kernel, so really, it didn't matter
what kernel they picked :(

Some are supported longer than others because we have developers willing
to do that support, for various different reasons (usually because it
makes their day-job easier).  There's no real specific reason to justify
any of the time lengths for them, sorry.

hope this helps,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]