-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/28/12 1:05 AM, Greg KH wrote:
Hi all,
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 way.
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. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQPMSRAAoJEB57S2MheeWyN8IP/jX7z//X3UYxGGaQBy0d5djy i3HaTTFX84SD34oGj/qINSdF853HwRWJbkwGIGue0cRmAtcM1nEgWIB9aiXbKlHR vTMmSXLhGRtPNz5wCBiCswSzQwy6XD7D6zbqrarOk356GngDAK5lGOVIsA3lllo/ lFE4otWqQ3KNUlFWxi7wsiuztyvlqyvLpojxDWknf40Xzz+CojNuR0tPay/87s5n C8QQzxoKPodIwAgn1DC6AmZDpFToFN/qhAEb4V+Fo9YlQosO+ljfiD7SdaO3Jr1n m9/bV2kBGeW/dgrKVL4iZf+FpjvqO8CCVA/Y8PwogWCTJu4tr1t4Bjal7jJHjdN+ 5EYEFkXmYXSU9X2YD2j5+sqPgZ3y6eu22wfqi8cVS2B7vBX70jGKyeUQ+Uw0e3hu rSVYL71EpB/L6s9GOrhqKmDfA+Be8sCoZBRI8Igzb8raWCdoI9DyHhL9EMTHheH0 ShvMbrfpLLMpfbG30SUSAgL5+RIHViDmmg8ORBsrsq5Fkmh7LkmwxFUdNqx5lGW8 T/UpJHWd5C79BCOBaF5VMSqb3K1X6RalW6VYQZnm1NWPv2m0vEy62VgP5q89LDTV ffwmSQj/CIZRg18D9P07tjVuligsyErc1FgTLrLQ6wzgC9A3X63qKl2KjFKVNkNv ol8PEMnNIaGczze7XjHg =H4IL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org