-----BEGIN PGP SIGNED MESSAGE-----
Hi folks -
The openSUSE team recently announced that openSUSE Factory is
moving to a rolling development model, similar to how Tumbleweed has
functioned for some time. I think this will do wonders for the
stability of Factory and hopefully make it interesting again for those
of us who used to sync nightly and zypper dup first thing every morning.
It does bring a few questions with it, though. How do we handle the
kernel with a rolling release? Having multiple outstanding versions
isn't an issue unique to the kernel, but few other projects are as
large and have as much churn between releases. The folks trying to
support the kernel as best we can are short on time as it is, so I'm
concerned about establishing parameters for which bug reports will be
considered valid. I'd like to define what those are so that anyone
going through bug reports (even someone not actively involved in
kernel development or maintenance) and see which ones can be closed
or, at least, put on hold until they've been reproduced with the
1) How do we handle releases of the Factory kernel?
2) What releases will be considered "supported" simultaneously?
For 1), I propose we make it official that Kernel:stable is now the
external repository for openSUSE Factory. Even though Factory has
already been pulling from Kernel:stable,
Does Kernel:stable always follow Linus' tree? Or does it wait and skip?
making it an official thing
means that security fixes and other backports are actively added to it
rather than it being Jiri's side project. Factory would only contain
point releases moving forward and release candidates would be confined
Would we have packages say on Kernel:HEAD to help folks on Kernel:stable
looking for a new driver / fix? By definition Kernel:stable will have to wait
until Linus' tree gets a fix merged before it trickles down unless we cherry
pick. If we want to reduce work on Kernel:stable having a pointer to
Kernel:HEAD rpms could be a way to get issues resolved a bit quicker once
submitted. I'm saying we could do that if we wanted to try to reduce work load
on factory and take advantage of existing development models which can help
users. Otherwise its a bit of work, not a lot, but it is some work.
As a result of the change, I'd start adding -rc1
updates to Kernel:HEAD rather than waiting until -rc2 as I have in the
past. It also means that there would no longer be a delay for things
like Xen and ARM in Factory.
Can you elaborate on the existing delay for Xen and ARM in existing
Factory? Would like to make sure I understand that.
As for 2), I'd like to hear suggestions. With only so much time to
devote to supporting the Factory kernel, we'll need to find a balance
between convenience for users and bugs actually getting fixed. We have
options between supporting every release (which I would actively
fight) and dropping support for any previous kernel as soon as a new
one is added to the repository. I've added some interested parties to
the CC list, but I'd like to hear from anyone with an opinion.
To be clear you are against supporting every release contiguously,
so say we 3.17 is released but we were on 3.16.2, we'd immediately
phase out 3.16.2 as soon as we release a package for 3.17.
This makes perfect sense to me. I'd be nice if we had an option to let users
select if they want to opt-in to rc release of packages as that would allow for
a streamlined way for users to get test packages being baked, which I suspect
will be useful for getting users to test before reporting / following up on a
fix. A kind of *self help service*. I wonder if Gentoo has something similar,
Vlastimil? This could be a generally useful thing, not just for the kernel.
Furthermore if we had an option to use a "vanilla" kernel then we could use the
latest and greatest kernel:HEAD with no delta and give users the ability to
report directly to kernel.org. That could be another way of *self helping*, and
getting folks more engaged upstream.
Related to 2, I'd like to put more effort into trimming down the
number of patches we carry in the openSUSE kernel. Over the years,
we've done a pretty good job of that (compare the number of patches in
a SLES release vs openSUSE), but we can do more. SUSE has already
hired several engineers to work on getting our divergent Xen
implementation into something that is mergeable upstream. Once that
happens, the openSUSE kernel patchset should only contain
My goal with xen is to kill any delta other than required backported
stuff, and that also should have a respective upstream commit. We
already have gobs of stuff we can nuke, so I wonder if testing it
out on Kernel:stable would be a good starting point?
 I'll be the first to admit we're open to criticism in how fast
openSUSE bugs are handled already
IMHO a rolling release should try to get users more in line with the
direct core communities involved to help with considerations on
resources on reports. For the kernel I would hope that this
would enable a similar approach, we should strive to keep folks
engaged upstream and the closer that is to the latest release the
easier I think it will be on both us and users.
A few points not yet addressed:
3) The kernel is now tied to systemd, so how are we going to pair those up
on OpenSUSE Factory?
4) Backports: if a user lacks support for a device driver they typically should
be uprading their kernel and if we're on the latest point release that should
suffice for many users. For the latest and greatest hardware though, those
components might only still be being baked. This may also be true if a series
of fixes or enhancements have been made to a device driver but not yet
released. This is where the backports project comes in. In terms of reducing
effort to deal with issues if a user is using a linux-next backport snapshot
and an issue is found they can be sure they can report it upstream to the
respective subsystems mailing lists or file a report on kernel.org. The chance
of the issue being a backport specific bug if on a recent kernel is extremely
low given that backporting consists about less than or = to about 1% of the
As I see it moving to a rolling release is a good way to get folks more
engaged with their respective upstreams, so any chance at that I think
is something we should take advantage of to help reduce our own work load.
Enabling use of rc releases of the kernel, specially if they are vanilla,
or backports should help with this.