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 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