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