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.
Dear Larry, dear other members of the (open)SUSE kernel-team/kernel list,
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.
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).
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.
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).
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…)
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?
> 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)
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…
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.
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.
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)
Is the policy on stable releases from kernel.org anywhere described?
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)
