On 10 January 2017 at 20:17, Takashi Iwai
Hi,
as we've started the development of openSUSE Leap 42.3, this question seems mandatory:
Should we - A) use a kernel based on SLE12-SP3 (4.4.x), or - B) fork an own branch based on 4.9.x?
The former is the way we did for openSUSE Leap 42.2. We keep the same code base as SLE12-SP2 while applying a slightly different kernel configs. This gives more test coverage by SUSE and other 3rd parties, and also much easier maintenance for security and other fixes.
Meanwhile, the latter is like what we did for openSUSE Leap 42.1. It has own branch based on the upstream stable tree. 4.9.x is supposed to be a LTS branch, so we can take it. This would require higher maintenance cost, and maybe receive less bug fixes from our side, in the end.
The biggest concern by (A) is that it's based on the 4.4.x kernel. It's rock solid, but it's old. It'll get fewer upstream stable updates later. Although SLE12-SP3 will cover some of new hardware (like Intel Kabylake platforms), it won't give the full list of new hardware in the market. 4.9.x covers a bit more than that.
You might think 4.9.x will be also old enough at the time of Leap 42.3 release. Right. If we really want to track a newer stuff, another alternative is - C) keep rolling until the next LTS kernel is released, then stick with LTS kernel.
The demerit of this method is, however, that you'll loose kABI compatibility until fixed with LTS, thus every KMP must be rebuilt before releasing the kernel update. So I find it a bit messy. If you want a rolling update, you can use TW, after all. But I'm open for this option, too. We might have a luck with the release date of LTS kernel.
Any comments, opinions and suggestions are appreciated.
thanks,
Takashi
I prefer A) and I strongly dislike B) or C) A) is my preferred as it avoids the reasons I explain below but also because it is the one that strongest preserves the promise that Leap is a stable distribution, based on SLE, using LTS kernels, kABI compatibility, that doesn't take risks in the name of shiny new things (we have Tumbleweed for that) Keeping with A) and perhaps moving to the next LTS kernel is a compromise I'd be prepared to consider supporting. It removes the 'based on SLE' promise but retains all the other promises we have made in regards to what Leap is meant to deliver. I do not consider the justification for B) or the rolling aspect of C) as valid, given that Leap 43.0 (based on SLE 13) is more than likely to be significantly less than 12 months after 42.3 Therefore the users who want a Leap with all the latest and greatest kernel will not have to wait long to get 4.9 or later (whatever is SLE 13). B) and C) also fully compromise many key promises of Leap. Rolling is not as stable as an LTS kernel and will not be well maintained for the full duration of Leap 42.3's support period. 4.9 MIGHT be as stable but ultimately we rely on non-SUSE/openSUSE contributors for that, and history has shown that when we use an openSUSE/SUSE maintained LTS kernel it serves us better - for starters we fix bugs that affect us in it, which as you mention is something that happens a lot less for other kenels. It all seems like a lot of risk and effort for not enough reward. Also I think this is the sustainable option for our openSUSE kernel maintainers to support. I am working hard to secure a longer support timeframe overlap than 6 months for 42.3 after 43.0's release. 42.3 might need to be supported beyond the release of 43.1 even. If you think you can do all that work well, fine, but please keep in mind Leap 42.3 is not a testbed for anything, it's going to be used in the real world, relied on, and likely relied on more than 42.1 or 42.2 are even because it will be the last of the 42.x series. I suppose you wouldn't like the workload of maintaining a Leap 42.3 branch of 4.9.x kernel for a long time in addition to everything else you'll be doing for Leap 43.0, Tumbleweed, and of course SLE 12 service packs and SLE 13 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org