Re: Next LTS release

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

 



Hi Willy,

On 06/08/2016 08:14 PM, Willy Tarreau wrote:
> 
> And even to limit the number of upgrades, first jump from one version to
> another until one is declared LTS and you can stick to it for as long as
> it is supported. Customers will prefer to run on a well-known LTS version
> than one you maintain yourself anyway, so they'll be willing to accept
> these small update steps for a few versions at the beginning. And they'll
> benefit from improvements.

Yes, that's the idea of a fallback if no LTS is available at the time we need to ship.
We were just wondering if we could avoid that little "instability" by directly picking a LTS version, if the schedules could be matched somehow, hence Marc's question about the time of the next LTS.

>From what has been said, we may still get a chance to start shipping with the next LTS, but we need such a fallback.

> 
>> 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.
> 
> I personally take over maintenance of the kernels we ship with our
> products, and we ensure to pick LTS kernels to save me from doing
> useless work. In the past we used to have quite a number of backports,
> and by catching up with more recent LTS versions we could get rid of a
> lot of patches and simplify our job. It also means that I have less
> extended LTS work to do, which is good considering that the difficulty
> grows with time. 

Indeed, this is exactly our point.
We'd like to avoid as much as possible the "useless work" you talk about.

>I definitely think that most users who absolutely need
> LTS kernels should proceed similarly, and that those who don't absolutely
> need LTS should use a recent enough kernel that is still actively maintained.
> 
> I'd also like to mention something regarding very long time maintenance
> for having worked on quite old kernels for some time (including 2.4).
> There's a point where the quality starts to decrease again due to bugs
> introduced in backports, just because the code is so much different that
> it's hard to get a backport right. I can't say how long it takes for a
> kernel to be screwed, but I definitely screwed 2.4 a few times, and would
> have screwed 2.6.32 many times if some careful reviewers had not spotted
> my mistakes in time. Reviewers will not participate forever to an antique
> release, and there will even be a moment where they will make mistakes as
> well. Just for this it's important to force customers to upgrade. Establish
> a 3-4 years plan if that works for you, but you need to enforce a deadline.

Thanks for your comments, they confirm our view on this regard.

Best regards,

Sebastian
--
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]