On Tue, Jan 10, 2017, at 02:17 PM, Takashi Iwai wrote:

Should we - A) use a kernel based on SLE12-SP3 (4.4.x), or - B) fork an own branch based on 4.9.x?

As a user, I would like to see a newer kernel used because of the poor support for current gen AMD cards in the older kernel. I'm on Tumbleweed and would prefer to be on Leap - I've seen others on the forum/reddit with similar issue. Thanks! -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 10 January 2017 at 20:17, Takashi Iwai wrote:

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

On mercredi, 11 janvier 2017 09.09:07 h CET Takashi Iwai wrote:

On Tue, 10 Jan 2017 20:45:25 +0100,

Jason DeRose wrote:

...

On Tue, Jan 10, 2017, at 02:17 PM, Takashi Iwai wrote:

...

Should we - A) use a kernel based on SLE12-SP3 (4.4.x), or - B) fork an own branch based on 4.9.x?

As a user, I would like to see a newer kernel used because of the poor support for current gen AMD cards in the older kernel. I'm on Tumbleweed and would prefer to be on Leap - I've seen others on the forum/reddit with similar issue. Thanks!

Well, the support for AMDGPU itself can be bumped for 42.3 even with 4.4.x kernel. We'll upgrade drm stack somehow up to 4.9 level for i915 Kabylake support in anyway, hence the rest are just (hundreds of) AMDGPU driver update patches :)

thanks,

Takashi Also Jason, with Leap it's still not too risky to use the kernel-stable repository, I know it is not a messy devel project ;-)

-- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Wednesday, 11 January 2017 9:55 Richard Brown wrote:

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)

For the record: option A, i.e. SLE12-SP3 based kernel, would not preserve kABI on upgrade from openSUSE-42.2. kABI is only preserved on maintenance updates, not when switching to new service pack. On the other hand, the risk of regressions would certainly be much lower than on switch to something like 4.9. Michal Kubeček -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 01/10/2017, 08:17 PM, Takashi Iwai wrote:

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 -

Either this -- I really love the SLE-openSUSE symbiosis here. The kernel receives care.

B) fork an own branch based on 4.9.x?

Hell, no! This was how openSUSE 13.2 (IIRC the number) ended up almost unsupported. The support for the kernel was really, really bad. And 4.9 won't be an LTS kernel too, AFAIK.

C) keep rolling until the next LTS kernel is released, then stick with LTS kernel.

Hmm, if there is no newer LTS at the 42.3 kabi freeze point, I would rather stick to 4.4 [A) above]. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 11 January 2017 at 17:08, Takashi Iwai wrote:

It'll be in a similar situation like Leap 42.1 which has 4.1.x-based kernel. It's less pain than openSUSE 13.2, while its support status is still far worse than Leap 42.2.

I'm not disagreeing with your point - I'd support any LTS kernel in Leap rather than a non-LTS kernel. But I have to share my very strong opinion that I do not consider all LTS kernels as equal. To be uncharacteristically undiplomatic, I favour SUSE/openSUSE maintained LTS kernels above non-SUSE/openSUSE maintainers LTS kernels. 4.1 was an LTS kernel, but not used elsewhere by SUSE/openSUSE and so relied purely on upstreams LTS support. It was in no way manner or form nearly as well maintained, with solid patches and backports for a long period of time, as 3.12 was (also used by SLE 12) or I assume 4.4 will be (as also used by SLE 12 SP2).

From my perspective, the work our kernel maintainers do on 'our' LTS kernels (ie. those used by SLE) is orders of magnitude better than 'the others'.

Even if this is a mistaken perception, there is no doubting that our maintainers are a lot more aligned and proactive in resolving issues that affect SUSE/openSUSE in the kernels they are actively maintaining as part of their work on SLE. One of the whole points of Leap is enabling the community to reap the benefits of SUSE's Enterprise maintenance of its codebase. The kernel is an important part of that and so I do not think we should dismiss it easily. I think the use the SLE 12 SP2 kernel is the option that brings the most benefit for the longest period of time to Leap 42.3 users. I realise that it _might_ disenfranchise some potential new hardware adopters, but in the case of 42.3 we know the kernel will have backports for stuff like Kaby Lake and AMDGPU. If that is not good enough we have the relatively close arrival of 43.0 to mitigate the issue, in addition to the existing mitigations of 'Tumbleweed' and the kernel_stable OBS repo. The more I think about it, the more I do not think its sensible to diverge 42.3's kernel from the SLE 12 SP3 one. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Wed, 11 Jan 2017 17:25:52 +0100, Richard Brown wrote:

I realise that it _might_ disenfranchise some potential new hardware adopters, but in the case of 42.3 we know the kernel will have backports for stuff like Kaby Lake and AMDGPU.

IIRC, AMDGPU isn't really targeted yet as SP3 update. But certainly it's doable. Feel free to open up either a FATE or a Bugzilla entry to track it. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 2017-01-12 09:32, Johannes Thumshirn wrote:

On Wed, Jan 11, 2017 at 05:26:08PM +0100, Jiri Slaby wrote:

...

On 01/11/2017, 05:08 PM, Takashi Iwai wrote:

[...]

...

...

It'll be in a similar situation like Leap 42.1 which has 4.1.x-based kernel. It's less pain than openSUSE 13.2, while its support status is still far worse than Leap 42.2.

Yes, I still prefer 4.4 -- I am aware we can lose users because of too old kernel.

IMHO that's partly a communication/marketing issue. Most people will read v4.4 and _think_ their new HW is unsopported just because they don't know there are backports.

FWIW, I would be OK taking a driver update needed by openSUSE and not so much by SLE into the SLE12-SP3 kernel, if it would make the A choice more attractive to openSUSE users. This is of course my personal opinion and not a promise to backport drivers for your newest usb missile launcher in SLE12-SP3. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 01/12/2017, 09:32 AM, Johannes Thumshirn wrote:

...

Yes, I still prefer 4.4 -- I am aware we can lose users because of too old kernel.

IMHO that's partly a communication/marketing issue. Most people will read v4.4 and _think_ their new HW is unsopported just because they don't know there are backports.

Not really -- I base on my own experience making linux work on machines of my wife, father, sister and friends. SLE kernel almost never worked on those because the laptops were new (no high-end machines, standard cheap notebooks, only new). Tumbleweed kernels mostly work on them. And over time (with new kernels), even touchpads and wifi upstream drivers start working. Not with SLE kernels. Despite of all that, I still prefer the SLE kernel. If people are able to make linux working on new machines, they are enough experienced to zypper ar Kernel:stable. Leap + K:stable usually cures most of the issues of new notebooks for me. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 01/12/2017, 12:19 PM, Stelian Ionescu wrote:

No, most likely what will happen is that they will install Ubuntu or Mint.

Do you mean Ubuntu * LTS 16.04 with 4.4 (the same as leap 42.3) and 5+ years support, or * non-LTS 16.10 with 4.8 with only 9 months support; tumbleweed has already newer kernel and comparable stability ? -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 12.01.2017 10:06, Jiri Slaby wrote:

Despite of all that, I still prefer the SLE kernel. If people are able to make linux working on new machines, they are enough experienced to zypper ar Kernel:stable. Leap + K:stable usually cures most of the issues of new notebooks for me.

Maybe there is a possibility to have this configuration sort of supported. Right now, the masses are preached "thou shalt not add any obs repositiories or you are going to burn in hell!". Maybe even updated boot disks with newer kernels could be made from time to time to allow installation on new hardware (it's hard to add Kernel:stable if the old kernel does not even boot). So the default would be SLE kernel, but there's an option somewehere in the system (it might be a pre-added but not activated Kernel:stable repository or some script that add the repo and installs a newer kernel in addition to the old one) that allows relatively unexperienced users make their system work. Of course with proper disclaimers in the documentation. (I personally don't care that much, as I generally only own obsolete hardware --newest non-embedded chipset is from around 2009-- and still run Kernel:HEAD on some of that just for fun) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 12 January 2017 at 12:05, Stefan Seyfried wrote:

On 11.01.2017 10:19, Bruno Friedmann wrote:

...

Also Jason, with Leap it's still not too risky to use the kernel-stable repository, I know it is not a messy devel project ;-)

Richard will not approve that option :-P

You might be surprised, see below :-P On 12 January 2017 at 12:23, Stefan Seyfried wrote:

On 12.01.2017 10:06, Jiri Slaby wrote:

...

Despite of all that, I still prefer the SLE kernel. If people are able to make linux working on new machines, they are enough experienced to zypper ar Kernel:stable. Leap + K:stable usually cures most of the issues of new notebooks for me.

Maybe there is a possibility to have this configuration sort of supported.

Right now, the masses are preached "thou shalt not add any obs repositiories or you are going to burn in hell!".

Maybe even updated boot disks with newer kernels could be made from time to time to allow installation on new hardware (it's hard to add Kernel:stable if the old kernel does not even boot).

So the default would be SLE kernel, but there's an option somewehere in the system (it might be a pre-added but not activated Kernel:stable repository or some script that add the repo and installs a newer kernel in addition to the old one) that allows relatively unexperienced users make their system work.

Of course with proper disclaimers in the documentation.

(I personally don't care that much, as I generally only own obsolete hardware --newest non-embedded chipset is from around 2009-- and still run Kernel:HEAD on some of that just for fun)

I quite like the idea. In order to do it in a way that I think I could approve (or more importantly, that would be a robust, sensible way for the openSUSE Project to stake it's reputation on) we would require something like the following criteria: 1. Some kind of formal submission review separate from the current Devel project informal-and-reviewer-can-be-submitter wild-west. This would be to catch obvious integration issues and to avoid single humans being responsible for major impacts to our users. I'm thinking something akin to the Factory or Maintenance review processes, but tuned to this specific case (That might be more or less robust than the two current examples, not sure). 2. Some kind of formal testing process. This would be to catch actual integration and functionality issues. I'm thinking something akin to the openQA testing we do for Tumbleweed or Maintenance Updates. This testing would have to be coupled to the release process of this "kernel:stable:tested" repo. I do not think it has to be as broad a test as we do for each Tumbleweed snapshot, but a relevant cross section to provide us with reasonable confidence that this "kernel:stable:tested" is at least approaching Tumbleweed levels of functionality & quality. 3. Some kind of formal release process. Which upstream kernel versions go in there? How long after their upstream release? For how long are they supported? How are security issues handled (AFAIK Security updates are not formally done on kernel:stable atm). How are the new releases announced? how are users meant to consume them? (ie. are they maintenance updates so zypper patch will handle them? or will it require users to do a zypper up?) With reasonable solutions to the above 3 criteria, I think we could take the first steps away from "thou shalt not add any obs repositiories or you are going to burn in hell!" and have the first example towards "these specific obs repositories are blessed, use them happily". Though, personally, I think the easier option is to just stick with the SLE kernel - but I do want anyone who likes this idea to consider the door to be open if they want to run through it. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On 2017-01-12 13:23, Stefan Seyfried wrote:

On 12.01.2017 10:06, Jiri Slaby wrote:

...

Despite of all that, I still prefer the SLE kernel. If people are able to make linux working on new machines, they are enough experienced to zypper ar Kernel:stable. Leap + K:stable usually cures most of the issues of new notebooks for me.

Maybe there is a possibility to have this configuration sort of supported.

Right now, the masses are preached "thou shalt not add any obs repositiories or you are going to burn in hell!".

Maybe even updated boot disks with newer kernels could be made from time to time to allow installation on new hardware (it's hard to add Kernel:stable if the old kernel does not even boot).

So the default would be SLE kernel, but there's an option somewehere in the system (it might be a pre-added but not activated Kernel:stable repository or some script that add the repo and installs a newer kernel in addition to the old one) that allows relatively unexperienced users make their system work.

Of course with proper disclaimers in the documentation.

(I personally don't care that much, as I generally only own obsolete hardware --newest non-embedded chipset is from around 2009-- and still run Kernel:HEAD on some of that just for fun)

As a user, I think this is what I would like. SLE kernel with an easy possibility to use another, possibly during install. And perhaps on the next Leap iteration, the mainline kernel would support that machine too. And it would have to be well explained. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-01-12 14:26, Carlos E. R. wrote:

On 2017-01-12 13:23, Stefan Seyfried wrote:

...

On 12.01.2017 10:06, Jiri Slaby wrote:

My email to the list got duplicated. It was not me, something at opensuse.org. I informed the list owner. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On Thu, 12 Jan 2017 14:33:11 +0100, Ludwig Nussel wrote:

Richard Brown wrote:

...

On 12 January 2017 at 12:05, Stefan Seyfried wrote:

...

On 11.01.2017 10:19, Bruno Friedmann wrote:

...

Also Jason, with Leap it's still not too risky to use the kernel-stable repository, I know it is not a messy devel project ;-)

Richard will not approve that option :-P

You might be surprised, see below :-P

On 12 January 2017 at 12:23, Stefan Seyfried wrote:

...

On 12.01.2017 10:06, Jiri Slaby wrote:

...

Despite of all that, I still prefer the SLE kernel. If people are able to make linux working on new machines, they are enough experienced to zypper ar Kernel:stable. Leap + K:stable usually cures most of the issues of new notebooks for me.

[...] So the default would be SLE kernel, but there's an option somewehere in the system (it might be a pre-added but not activated Kernel:stable repository or some script that add the repo and installs a newer kernel in addition to the old one) that allows relatively unexperienced users make their system work.

[...] I quite like the idea. In order to do it in a way that I think I could approve (or more importantly, that would be a robust, sensible way for the openSUSE Project to stake it's reputation on) we would require something like the following criteria:

1. Some kind of formal submission review separate from the current [...] 2. Some kind of formal testing process. This would be to catch actual [...] 3. Some kind of formal release process. Which upstream kernel versions [...]

What about just using maintenance updates? All points solved there already.

Right, it can be done in a similar manner as TW, but do MR instead of SR. We may even delay the submission until 4.x.1 or later is released, where usually it catches up the pending stable fixes, and often regressions are already covered there. (BTW, we do care security fixes on Kernel:stable, too; usually it ends up with just a +1 version bump in the case of stable branch, thus it doesn't look obvious like others.)

That "latest upstream kernel" just needs a name != kernel-default so it can coexist in the official repo.

It's a dilemma. We certainly want to avoid the growth of kernel flavors, while it looks inevitable in this case... One another question is how to keep 3rd party drivers (Nvidia, VMware, VirtualBox, etc) working with this. If the 3rd party support is assured, it's a really good option, IMO. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Thu, 12 Jan 2017 18:09:37 +0100, Andrei Borzenkov wrote:

12.01.2017 17:55, Jiri Slaby пишет:

...

On 01/12/2017, 01:55 PM, Stelian Ionescu wrote:

.

...

only start sort of support it. Actually, we somehow do already. When a report to Tumbleweed kernel arrives, I mostly do not care with which userspace, because it is most of the time irrelevant anyway.

Suppose new kernel causes user space breakage (not something unheard of) and it requires user space patches/updates. What will be support situation on openSUSE? Ubuntu fully supports HWE stacks as part of LTS release. Can we expect other maintainers to work on bugs caused by "too new kernel" on Leap?

It's basically a kernel bug. Except for a few cases (e.g. the requirement of a new firmware), the kernel should be fixed instead. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Am 12.01.2017 um 18:09 schrieb Andrei Borzenkov:

Suppose new kernel causes user space breakage (not something unheard of)

Care to give an example? Not just hearsay? Just complain to Mr. Torvalds and he'll have the committer of the breakage fix the code. What might sometimes be needed could be an update of supporting tools (dracut or such), but these are rare cases in my experience. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Fri, 13 Jan 2017 09:55:09 +0100, Ludwig Nussel wrote:

Stefan Seyfried wrote:

...

Am 12.01.2017 um 18:09 schrieb Andrei Borzenkov:

...

Suppose new kernel causes user space breakage (not something unheard of)

Care to give an example? Not just hearsay?

For example the usb breakage I reported in November here on this list.

Ironically, this is a good example showing why the rolling kernel update is a good thing. Such a breakage can be more easily and quickly found by the frequent update, and thus covered / checked in a timely manner. But in your report above, it was the jump from 3.16.x to 4.4.x. It's way too wide to spot out a problem. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Fri, 13 Jan 2017 14:47:35 +0100, Andrei Borzenkov wrote:

12.01.2017 21:46, Stefan Seyfried пишет:

...

Am 12.01.2017 um 18:09 schrieb Andrei Borzenkov:

...

Suppose new kernel causes user space breakage (not something unheard of)

Care to give an example? Not just hearsay?

Just complain to Mr. Torvalds and he'll have the committer of the breakage fix the code.

What might sometimes be needed could be an update of supporting tools (dracut or such), but these are rare cases in my experience.

Yes, I do mean low level tools like dracut, udev, systemd. They are usually sensitive to kernel changes and need to adapt to newer versions (not other way round).

Well, you still didn't give the example that actually happened... Usually, it's the other way round: when a newer kernel provides a new feature and a user-space program wants to use it eagerly, such a program needs the update. But the old binary runs as is if it doesn't need a new feature. (Otherwise, how many people could use Kernel:stable on Leap and older distros...?) And, a drastic kernel change that causes incompatibility is enabled usually only via a specific kernel config. If a new kernel forces incompatibility inevitably, it's a clear regression, and we must report back it as a bug. In a long term, we see incompatibility sometimes, yes. For TW, we tend to enable such a new config as soon as provided. It's fine for a rolling release like TW. But it doesn't mean that we have to turn it on always for Leap as well. If it brings incompatibility, we can just skip such a config for the Leap version of Kernel:stable. The incompatible switch may happen at the next Leap version up together with user-space updates, while compatibility can be kept during the same Leap version deployment, at least. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Hi, On 01/10/2017 08:17 PM, Takashi Iwai wrote:

B) fork an own branch based on 4.9.x? I asked around in the Hungarian openSUSE community. The majority of responses suggested 4.9 or whatever the latest LTS kernel is. Admittedly most of them are desktop users, not server guys, wanting their latest gadgets supported...

My preference is also 4.9 or later LTS, but for a completely different reason: this is where tons of ARM support was merged. Bye, CzP -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Dne 12.1.2017 v 09:56 Michal Kubecek napsal(a):

infiniband, fiber channel, SCSI storage, multipath etc. I'm afraid openSUSE customers would be rather interested in things like recent graphics or sound chips sold in consumer grade segment. Just an example: are we going to do backports of radeon driver when we tell SLE customers not to use it?

While I get your point, we are not as bad with respect to graphics. In particular, the radeon driver is supported in SLE and it's possible it will get an update. But sure, there exists hardware which does not receive much attention as part of the SLE efforts, but some openSUSE users want to use it.

I must say I'm pleasantly surprised that so far most of those who provided their opinion prefer SLE12-SP3 based kernel, personally I didn't expect this option to have any real chance. On the other hand, when I take a look at the names, I don't really think it's a representative sample of openSUSE user base.

We can stop the discussion right before the other options gain substantial support and call it meritocracy :-). Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

On Mon, 16 Jan 2017 13:48:32 +0100, Takashi Iwai wrote:

As we've discussed, another option should be taken into account, too:

D) create a new kernel flavor to follow the upstream (Kernel:stable)

... so that user will be able to install both this new kernel and the kernel-default based on SLE12-SP3 kernel.

I remember proposing this model several years ago ;-) I'm even dreaming of an integration into the installation process, that would check the device IDs and suggest the latest kernel by default, if it supports devices which the default kernel doesn't. I'm aware this isn't a bullet-proof heuristic, but it would still make life easier for many users. -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org