-----BEGIN PGP SIGNED MESSAGE-----
On 8/28/12 1:05 AM, Greg KH wrote:
As part of one of the Linux kernel Summit discussions today, it
was brought up that after a kernel is released (for example 3.5),
it's a bit too late to be doing testing to see how well it is
working out. The .0 release is usually a bit rough, and it takes
until the .1 or .2 release to get most major issues out of the
So, the kernel developers would like to get a wider range of
testing, and one thing proposed would be to have rolling distros
switch their kernel over a bit earlier to the new release than they
had been doing. Specifically, around the -rc5 point in time would
be great. That way, any reported regressions could be fixed sooner
and get into the final .0 release for everyone to use.
Now this does place a bit of a larger burden on the users of those
distros to be diligent in reporting problems, and the distro
engineers to report the issues upstream as well, but it sounds like
a reasonable thing to try out.
So, for the next kernel release, I'm thinking of switching the
kernel in Tumbleweed over to 3.6 at the -rc5 timeframe. Does
anyone strongly object to this happening?
- From a technical perspective, it doesn't make much difference to me.
The first step in triaging non-obvious Tumbleweed kernel bugs is to
ask that the reporter reproduce with a kernel-vanilla from the same
vintage anyway. Unless effort comes in from elsewhere, Tumbleweed
kernels will never get as much attention as release kernels.
However, and several other replies have noted this as well, it seems
that this strategy is conflating the goals of the upstream kernel
community with those of the Tumbleweed project. The benefit to the
upstream kernel community is obvious -- but I'm not seeing the up-side
for Tumbleweed users. Tumbleweed *isn't* Factory, nor should it be. I
think you'll find that if the kernel becomes even less stable in
Tumbleweed, users will either stop using it or start marking the
kernel packages as Taboo for update until a .0 is released.
If the goal is test coverage, I think the best way to do that is to
make pre-built kernels available for users who want to participate in
that process. Co-opting Tumbleweed isn't the way to do that.
We already have Kernel:HEAD for that and I sync that starting with
- -rc2. I've (we've?) have that policy for years, but now that Jiri has
been maintaining Kernel:stable for a while, it may be time to make
Kernel:HEAD even more aggressive and start with -rc1. Sure, it can lag
a little behind for things like Xen, but the upstream testing
community doesn't care about that anyway. Perhaps the answer is to
come up with a way to allow users to ride the bleeding edge without
having to hunt down OBS published repo URLs themselves.
FWIW, using -rc1 in HEAD doesn't increase my work effort much. It
would probably lessen it, even, since I merge -rc1 as soon as it's
released and then update to -rc2 before pulling into master anyway.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----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