On 12 January 2017 at 12:05, Stefan Seyfried
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
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
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(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org