Possible change in kernel philosophy

Jiri Slaby posted the following on the openSUSE kernel mailing list:

===============================================================
Hello,

at SUSE, we are currently discussing the future of merging releases
from -stable kernel tree[1] into SLE. There is a fear of regressions
caused in the enterprise distribution as well as a fear of high patch
count which in most cases cannot be reviewed properly with our power.

I would like to know your opinion about merging -stable kernels into
openSUSE.

This means:

  • do you prefer to stay with the latest stable kernel released at the
    time an opensuse distro becomes available? (And then only single fixes
    for reported bugs are merged.) Or should be -stable releases
    incorporated as soon as they are out (or later).
  • Regarding the parentheses, would you prefer some time to pass before
    a -stable kernel is committed to a particular openSUSE kernel?
  • Did you hit some regression caused by stable releases (this is
    rather information for me personally). If so, how often?

Note that Kernel:stable (and Tumbleweed) will be unaffected by the
result of this thread. It will still follow the latest stable upstream
release as soon as possible.

Opinions welcome.

[1] The releases numbered by the third numbers after major release
numbers, e.g. 3.2.1 or 3.2.2.

thanks,


js
suse labs

================================================================

If you have any thoughts on this issue, I will pass a summary back to Jiri.

Larry

I’m happy to see it, so long as the old kernels remain in the repos as they do now

Dear Larry, dear other members of the (open)SUSE kernel-team/kernel list,

  1. Instead (or in addition to)
    the “(or later)”/‘stable-kernel after a period of time’ variation
    I would prefer if such new openSUSE kernel politics would be be combined
    with a kernel fallback mode (in default* not only as a non-default
    option). Something like keeping every time two kernel versions (at least
    for a given time like a month) and so also an easy possibility for
    testing the new kernel with many testes without much fuss for them.

  2. I think that many users do use old hardware with openSUSE (or at
    least like me one old pc/laptop [in my case with intel i915 graphic] and
    one new device). For them may be the risk that their hardware would not
    be supported suddenly (in my amateurish view).

  3. For users with graphic from AMD or NVIDIA it may become even more
    problematic to get their system working with 3D support (which is for
    example needed for GNOME3 without fallback mode.

  4. I guess there may be too less distinction from the Tumbleweed version

  • the now ‘normal’ versions may become something like Tumbleweed without
    old desktop environment (GNOME, KDE, …) - Tumbleweed not reloaded (in
    contrast to nowadays GNOME reloaded or KDE reloaded).
  1. If this is change is wanted (especially by SUSE and for the
    professional versions) - maybe the whole concept of openSUSE versions,
    lifetime and cooperation with the payed/professional SUSE versions
    should be ‘re-thought’ also?
    Something like:

a) Factory (only for testing based on kernel new and the according
desktop environment)

b) Tumbleweed (for the very curious user and as a second installation
for testing for the masses)

c) Main (Tumbleweed a bit more conservative - like all changes 2 months
after Tumbleweed)

  • named after the kernel version or like now with a new name with the
    n.1, n.2, n.3 schema but changes synchrony to the change of the kernel
    version (n may depend also on the d) versions )-

[c’) The _SUSE versions [at least SLED for the Desktop] based on
openSUSE Main]

d) Conservative (periodical forked from Main based on long term support
kernels) - for example based on every second long term kernel or ca.
every/every second/fourth/sixth/… year ‘new’ with 2 months of
overlapping time) maybe named n.O like openSUSE 13.0, 14.O … or
openSUSE <kernel-number> Conservative

? d’) The (other) professional SUSE versions (for Server - SLES or for
conservative Servers SLECS/SLESC) based on openSUSE Conservative for
example openSUSE Conservative +2 mounths ?]

Just my bold amateurish thinking/brainstorming (I am only a layer…)

Regards
Martin (Seidler)

P. S. Sorry for my terminological confusion:

I meant the versions that are going to become the next stable kernels (release candidates) - the kernel.org term for those seems to be mainline n version or just “mainline”.

Reading [opensuse-kernel] -stable kernel releases into openSUSE?](http://lists.opensuse.org/opensuse-kernel/2012-02/msg00008.html) and following I think I probably misunderstood that part:
Meant is if a openSUSE release starts for example by 3.2.1, it would be updated to 3.2.2 if this version would be available (or a time after that…), right?

On 2012-02-01 19:54, pistazienfresser wrote:

I don’t like the idea.

> 3) I think that many users do use old hardware with openSUSE (or at
> least like me one old pc/laptop [in my case with intel i915 graphic] and
> one new device). For them may be the risk that their hardware would not
> be supported suddenly (in my amateurish view).

True.

> 4) For users with graphic from AMD or NVIDIA it may become even more
> problematic to get their system working with 3D support (which is for
> example needed for GNOME3 without fallback mode.

That is also a problem. Proprietary drivers will not follow that fast, I’m
afraid.

I prefer the released openSUSE version to remain with the same kernel as
released at first, with the necessary updates as is currently done.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Yes
It would require that those drivers were ready and available before updates were passed through

On Thu, 02 Feb 2012 05:16:02 +0000, caf4926 wrote:

> Yes It would require that those drivers were ready and available before
> updates were passed through

That would be my biggest concern with the change as well.

On the other hand, it would make incorporating changes like the ones
needed for my touchpad easier. (It’s fixed in the 3.2 kernel, but
backporting it to 3.1 apparently isn’t a trivial thing). So the question
then becomes one of making it easier for users of more commonly-used
hardware that uses closed drivers, or making it easier for users of less
commonly-used hardware where the vendors have made it easier to include
OSS drivers…

Not an easy question to answer.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

I suppose really, the option to use the newer kernel is already there. We just have to add the repo or compile. For advanced users, this is not a big issue.

Question is: Will it making the latest stable available in OS by default cause problems?
Answer: Probably, yes.

Would I like to see it? Yes.
But I don’t want something implemented unless it done well.
Though I suspect our concerns about proprietary drivers might go unheard.

On Thu, 02 Feb 2012 05:56:02 +0000, caf4926 wrote:

> Would I like to see it? Yes.

Agreed.

> But I don’t want something implemented unless it done well.

Also agreed.

> Though I suspect our concerns about proprietary drivers might go
> unheard.

I don’t know that ‘unheard’ would be accurate; Larry did say he’d
summarize the thoughts and pass them back. There is an important
distinction between not hearing the concerns and weighing the concerns
and deciding that there are other overriding concerns that push a
decision in a direction that we may not agree with.

I appreciate Larry taking those concerns back to those making the
decision, regardless of the outcome.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On Thu, 02 Feb 2012 06:02:49 +0000, Jim Henderson wrote:

> I appreciate Larry taking those concerns back to those making the
> decision, regardless of the outcome.

By which, of course, Carl, I don’t mean to imply that you don’t
appreciate it. :slight_smile:

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On 2012-02-02 06:21, Jim Henderson wrote:
> On Thu, 02 Feb 2012 05:16:02 +0000, caf4926 wrote:
>
>> Yes It would require that those drivers were ready and available before
>> updates were passed through
>
> That would be my biggest concern with the change as well.
>
> On the other hand, it would make incorporating changes like the ones
> needed for my touchpad easier. (It’s fixed in the 3.2 kernel, but
> backporting it to 3.1 apparently isn’t a trivial thing). So the question
> then becomes one of making it easier for users of more commonly-used
> hardware that uses closed drivers, or making it easier for users of less
> commonly-used hardware where the vendors have made it easier to include
> OSS drivers…

Those people can use experimental kernels or factory or tumbleweed. Or KOTD.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 2012-02-02 06:56, caf4926 wrote:
> But I don’t want something implemented unless it done well.
> Though I suspect our concerns about proprietary drivers might go
> unheard.

It breaks gnome 3


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Or maybe something like
a) a repository kernel-previous with security-updates for kernels from the version before the actual used kernel - that would be also a rolling kernel (with the same speed rolling but always a version older)
b) a repository kernel-freezed for kernels like the version in the openSUSE-release with only security updates
(alike the openSUSE kernel policy now) ?
Regards
Martin

pistazienfresser wrote:
> Or maybe something like
> a) a repository -kernel-previous- with security-updates for kernels
> from the version before the actual used kernel - that would be also a
> rolling kernel (with the same speed rolling but always a version older)
> b) a repository -kernel-freezed- for kernels like the version in the
> openSUSE-release with only security updates
> (alike the openSUSE kernel policy now) ?

Sounds very complicated. If you’re on kernel-previous and an update to
it breaks on your system, what do you do? I’m not sure what problem your
suggestion solves.

Hä? In my view b) is more or less changing of option and default compared with nowadays (main) update-repository and kernel-stable-repository.

Would you expect a big amount of such cases?
I thought the kernels in the kernel-previous repository wound be mostly the same as the ones that were in the update repository a few months before.

You meant alternative b)?
aa) see above (probably more stability as option if wanted)
bb) I thought for example the graphic manufacturers would have a few months more time to develop fitting drivers.

But as written before, this is only brainstorming from my amateurish point of view.
Regards
Martin

On Thu, 02 Feb 2012 10:53:06 +0000, Carlos E. R. wrote:

> On 2012-02-02 06:21, Jim Henderson wrote:
>> On Thu, 02 Feb 2012 05:16:02 +0000, caf4926 wrote:
>>
>>> Yes It would require that those drivers were ready and available
>>> before updates were passed through
>>
>> That would be my biggest concern with the change as well.
>>
>> On the other hand, it would make incorporating changes like the ones
>> needed for my touchpad easier. (It’s fixed in the 3.2 kernel, but
>> backporting it to 3.1 apparently isn’t a trivial thing). So the
>> question then becomes one of making it easier for users of more
>> commonly-used hardware that uses closed drivers, or making it easier
>> for users of less commonly-used hardware where the vendors have made it
>> easier to include OSS drivers…
>
> Those people can use experimental kernels or factory or tumbleweed. Or
> KOTD.

With the side effect, though, of making it easier for vendors who
distribute proprietary binary blob drivers rather than actually
supporting open source driver development.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On 2012-02-02 23:08, Jim Henderson wrote:
> On Thu, 02 Feb 2012 10:53:06 +0000, Carlos E. R. wrote:

> With the side effect, though, of making it easier for vendors who
> distribute proprietary binary blob drivers rather than actually
> supporting open source driver development.

Which is not a bad thing, IMO.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

A few additional questions:

  1. Is the policy on stable releases from kernel.org anywhere described?
  2. What should happen in the new proposed openSUSE kernel policy if a stable tree ( e. g. 3.1.x) would not be longer maintained from kernel.org?
    2.1) If 3.1.17 would be the last released number: Would 3.1.17 after that only get updates for reported bugs like 3.1.9 nowadays for 12.1?
    or
    2.2) Will there also be a change to the next stable tree - for example t 3.2.x tree after the end of the 3.1.x tree?
    or
    2.3) Will it anyhow be ensured that the chosen -stable tree will be updated/maintained for the whole lifetime of the according openSUSE release version? (By volunteering a openSUSE/SUSE/… member as maintainer or by choosing a version with long support from kernel.org) at release time?)

By the way: the documentation of kernel and kernel policies in openSUSE may be worth a try to improve it (hopefully by someone with the according [internal] knowledge) - for example on
Kernel - openSUSE
there is no description of the PAE flavor
and the description of the differences between the default and the desktop openSUSE kernel flavor[1] is probably be worth an improvement.

Regards
Martin

[1] An actual test in the Linux Magazin (German version of Linux [Pro] Magazine) shows big differences in the power consumption on the same device. Especially with the LXDE desktop - kernel default 11.5 Watt, kernel desktop 19.9 Watt with openSUSE 12.1
(Markus Feilner, Tim Schürmann, Michael Kromer: Stromfresser entlaven : Tipps, Tricks und Tools, mit denen Notebooks länger laufen. Linux Magazin 3/12, Seite 22-30, 24, 2012-02-02)

Like it is already the case now (or with the next bug of relevance) for the 3.1.x stable tree:
Gmane Loom

From: Greg KH <gregkh <at> suse.de>
Subject: Linux 3.1.10
Newsgroups: gmane.linux.kernel, gmane.linux.kernel.stable
Date: 2012-01-18 15:46:09 GMT (2 weeks, 5 days, 1 hour and 38 minutes ago)

I’m announcing the release of the 3.1.10 kernel.

All users of the 3.1 kernel series must upgrade.

This is the LAST release of the 3.1 kernel series, please move to the
3.2 kernel series at this time. Again, 3.1.y is end-of-life…]

Regards
Martin