-----BEGIN PGP SIGNED MESSAGE-----
On 9/11/14, 2:05 PM, Luis R. Rodriguez wrote:
On Thu, Jul 31, 2014 at 10:32:06AM -0400, Jeff Mahoney
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 latest version.
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
Kernel:stable is essentially Kernel:HEAD that doesn't follow release
candidates. Instead, it follows the -stable branch. So while
Kernel:HEAD will occasionally get a x.y.z.1 before an -rc2 is
released, Kernel:stable will accumulate stable updates for several months.
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 to Kernel:HEAD.
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
Kernel:stable won't just be a packaged up version of the stable git
repository. Fixes would be merged there in the same manner they are in
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.
Sure, there's no reason why not. There might be issues introduced by
it being a release candidate, but if we can focus on one aspect even
in the face of other problems, it could 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.
The existing delay is because I defer porting of the Xen patches to
the Xen team (typically Jan Beulich) and defer changing the configs
for the ARM architecture to the ARM maintainers because they tend to
be pretty specific to a particular board and I don't want to
accidentally introduce bloat that only gets discovered later when
someone wonders why the kernel has grown.
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
could be another way of *self helping*, and getting folks more
That opt-in is adding the Kernel:HEAD OBS project repository. We also
do have a -vanilla option: The kernel-vanilla package. These are tools
we already use as part of the triage process.
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 security/stability backports.
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?
Yeah, absolutely. The usual caveat about maintaining compatibility
applies, of course.
 I'll be the first to admit we're open to criticism in how fast
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org