On 10 January 2017 at 20:17, Takashi Iwai <tiwai(a)suse.de> wrote:
as we've started the development of openSUSE Leap 42.3, this question
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 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
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
Any comments, opinions and suggestions are appreciated.
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
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
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(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org