On 28 August 2012 06:05, 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?

I don't see any issue with switching earlier, other than finding some bugs sooner :-) Most people that run Tumbleweed are generally living on the edge of their seats so should be more than capable of reporting bugs. I find you proposal sane (well as sane as anything is), and as such should be implemented. Regards, Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 28.08.2012 07:50, schrieb Greg KH:

On Tue, Aug 28, 2012 at 07:10:34AM +0200, Wolfgang Rosenauer wrote:

...

Am 28.08.2012 07:05, schrieb Greg KH:

...

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?

I do not strongly object (I do not use TW atm anyway) but I have a question: Where do you draw the line?

It's up to the maintainer of the package and a discussion with the Tumbleweed developers, don't you think?

Makes sense. And perfectly fine for me. Just was curious about a statement. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2012-08-27 at 22:05 -0700, 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?

No strong objection, but a minor comment.. In practice, rc5 vs .0 probably won't make much difference at all, but more users will be bitten, else the move was a failure. So this move explicitly plans on users being bitten, detracting from Tumbleweed's rolling ~stable allure, _evading_ developmental regression detection and reporting duties being a major attractor to running rolling ~stable ;-) -Mike -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Aug 27, 2012 at 10:05:23PM -0700, 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 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?

No objection but a hint from the RPM packaging side we can share from our Samba packaging service. We provide alpha, beta, and RC version there¹ too. And this causes trouble to RPM as 3.6.0-rc5 is always larger than the final 3.6.0 from the alphanum comparison. This is a limitation of RPM. Some might suggest to use the epoch feature but even that would not help at the long run.² Anyhow, we've found a dirty solution for the alpha, beta, RC suffix. We tweak with the RPM version string. By this the RPM has 3.6.0 in the resulting filename while the binaries identify themself as 3.6.0-rc5 at startup with -V or in the log files. That's enough to identify a alpha, beta, or RC relase. As soon as the final 3.6.0 got published we update network:/samba:/STABLE/ and ensure to use a release greater than the last one we used with the last one used in the network:/samba:/TESTING/ We might only use an rpm unfriendly string (3.6.0rc5 compared to 3.6.0-rc5). If that's the case sorry for the noise. Cheers, Lars ¹ http://download.openSUSE.org/repositories/network:/samba:/TESTING/ ² The limitations defined by the SUSE packaging rules are a different topic. -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Tue, Aug 28, 2012 at 5:19 AM, Lars Müller wrote:

No objection but a hint from the RPM packaging side we can share from our Samba packaging service. We provide alpha, beta, and RC version there¹ too. And this causes trouble to RPM as 3.6.0-rc5 is always larger than the final 3.6.0 from the alphanum comparison.

This is a limitation of RPM. Some might suggest to use the epoch feature but even that would not help at the long run.²

I've been tagging my packages (which also do beta and rc releases) as "final" (when the final release happens). 3.6.0-final would be larger than 3.6.0-rcn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Aug 28, 2012 at 08:55:56AM +0200, Mike Galbraith wrote:

In practice, rc5 vs .0 probably won't make much difference at all, but more users will be bitten, else the move was a failure. So this move explicitly plans on users being bitten, detracting from Tumbleweed's rolling ~stable allure, _evading_ developmental regression detection and reporting duties being a major attractor to running rolling ~stable ;-)

That's a really good point. I guess I'm abusing my role here as both a kernel developer who wants to see stable kernels released by the community, and as the Tumbleweed maintainer, sorry about that. I'm all for helping kernel.org developers out, but at the expense of people who are counting on Tumbleweed to not mess their systems up, I probably shouldn't do that, as you and Lars and others point out. Let me talk to James Bottomley about this a bit more, he's the one that proposed doing this yesterday in the meeting, as well as talking with David from Fedora, and see if there's some other way we can come up with that can help out. Maybe just have a Tumbleweed:Kernel repo that people can add to get this newer kernel if they want to be on even more of a bleading edge, that would like to the proper Kernel:HEAD release at the -rc5 time period. Perhaps that might balance the needs of users better? greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Aug 27, 2012 at 10:15 PM, Andrew Wafaa wrote:

On 28 August 2012 06:05, 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?

I don't see any issue with switching earlier, other than finding some bugs sooner :-) Most people that run Tumbleweed are generally living on the edge of their seats so should be more than capable of reporting bugs. I find you proposal sane (well as sane as anything is), and as such should be implemented.

Regards,

Andy

-- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

As a long-time "edge of the seats" Linux desktop/laptop user (I started at Red Hat 6.2 and ran Gentoo testing for years) I'm going to disagree. A rolling release is fine for anything *but* the kernel. As far as I'm concerned, the boot loader, kernel, filesystem checks, X windows, networking / wifi, sound cards, etc. - everything that does its magic up to the point where the display manager asks me to log in - needs to be stable and signed off on by some kind of human / machine QA process. I'd like to see some kernel software metrics - bug finding rates / reporting rates / closing rates, average number of days between the last kernel release candidate and stable, etc. I'm fine with GNOME, KDE, Firefox, LibreOffice rolling releases. Hell, I run most of my scientific applications and eBook publishing tools compiled from upstream tarballs and some things even from version control repositories! But the kernel - no! Once I have filesystems, network, audio and video working I don't want to be part of the troubleshooting efforts on them again. -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://j.mp/QCsXOr How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

In SUSE Studio terms, if I build a Tumbleweed appliance with the "Server" template, I want everything in it solid. And I'd add the tool chain - gcc / make / bash / vi / grep and friends - to the list of things that need to be solid / non-beta whether or not they're in Tumbleweed. On Tue, Aug 28, 2012 at 9:40 AM, M. Edward (Ed) Borasky wrote:

On Mon, Aug 27, 2012 at 10:15 PM, Andrew Wafaa wrote:

...

On 28 August 2012 06:05, 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?

I don't see any issue with switching earlier, other than finding some bugs sooner :-) Most people that run Tumbleweed are generally living on the edge of their seats so should be more than capable of reporting bugs. I find you proposal sane (well as sane as anything is), and as such should be implemented.

Regards,

Andy

-- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

As a long-time "edge of the seats" Linux desktop/laptop user (I started at Red Hat 6.2 and ran Gentoo testing for years) I'm going to disagree. A rolling release is fine for anything *but* the kernel. As far as I'm concerned, the boot loader, kernel, filesystem checks, X windows, networking / wifi, sound cards, etc. - everything that does its magic up to the point where the display manager asks me to log in - needs to be stable and signed off on by some kind of human / machine QA process.

I'd like to see some kernel software metrics - bug finding rates / reporting rates / closing rates, average number of days between the last kernel release candidate and stable, etc. I'm fine with GNOME, KDE, Firefox, LibreOffice rolling releases. Hell, I run most of my scientific applications and eBook publishing tools compiled from upstream tarballs and some things even from version control repositories! But the kernel - no! Once I have filesystems, network, audio and video working I don't want to be part of the troubleshooting efforts on them again.

-- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://j.mp/QCsXOr

How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs?

-- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://j.mp/QCsXOr How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, August 28, 2012 05:18:27 PM Jos Poortvliet wrote:

Actually, I'd personally prefer to move to a new kernel in the .1 times instead - have Tumbleweed MORE stable instead of less.

Rationale: IF we take Tumbleweed as a prominent way for people to get newer oS software between releases (especially important if we lengthen the release cycle, which is at least on the agenda), Tumbleweed should become MORE, not less stable.

Factory would be where RC's of kernels get tested, and so would a possible tumbleweed-testing repository. For me as end user, I don't use Tumbleweed for testing (that's what Factory is for, imho) but to have newer software without waiting 8 months. Making it less stable would make me leave Tumbleweed and run the latest openSUSE with a large number of OBS repo's again (as I did before Tumbleweed).

But this choice comes down to a philosophical question: what's tumbleweed for? Is it (as we currently advertise) a STABLE rolling release of openSUSE or is it a testing ground for new software?

My choice would be obvious from what I wrote.

Note that imho the choice of what Tumbleweed is for lies with the Tumbleweed maintainer - that's you. But I'd highly recommend changing our promotion of Tumbleweed if you do this (and similar steps in the direction of a more Factory-like Tumbleweed): it should no longer be promoted to our average user.

And, if this is done, I'd advocate for either shortening or at least NOT lengthening our release schedule, OR creating a new, STABLE tumbleweed branch which IS meant for end users.

/Jos

WOW Jos, I could not agree with you more! Very well said! I have already had Kernel updates on Tumbleweed keep my system from booting and then I either lock the kernel package and keep the old one or just change grub to boot from a kernel that worked... I would prefer not to have to do this more because of RC kernels. As you pointed out Factory is where testing of new kernels and such should be done. I would LOVE for a more stable Tumbleweed, but really, please lets not make it less stable. Thanks, -- Drew Adams openSUSE Member & Ambassador, openSUSE Project -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Aug 28, 2012 at 4:52 PM, Dimstar / Dominique Leuenberger wrote:

That's actually not true: 3.6.0-rcX > 3.6.0-final (simply because r > f)

Lol, sorry, you're right, we use beta instead of rc so it would work because b < f ;) In any case, the trick is the same -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Achim Gratz [08-28-12 13:33]:

Greg KH writes:

...

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.

While I understand the idea, I am one of those Tumbleweed users that do not have a dedicated test machine or even test partition so I'd really have to think about sticking with Tumbleweed if this became the new policy. I usually have the three latest kernels installed, so I can go back if one of the updates makes problems, but there are times where I wouldn't want to bear this added risk. Besides, the way Tumbleweed was advertised in the past does not really fit to what it would become with that change. I'd suggest putting the not-quite released kernel stuff into a different or add-on repo so that everyone can opt in or out by activating the correct repo.

this appears a *reasonable* approach, with wide publication -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2012-08-28T06:46:46, Greg KH wrote:

On Tue, Aug 28, 2012 at 08:55:56AM +0200, Mike Galbraith wrote:

...

In practice, rc5 vs .0 probably won't make much difference at all, but more users will be bitten, else the move was a failure. So this move explicitly plans on users being bitten, detracting from Tumbleweed's rolling ~stable allure, _evading_ developmental regression detection and reporting duties being a major attractor to running rolling ~stable ;-)

That's a really good point. I guess I'm abusing my role here as both a kernel developer who wants to see stable kernels released by the community, and as the Tumbleweed maintainer, sorry about that.

I'm all for helping kernel.org developers out, but at the expense of people who are counting on Tumbleweed to not mess their systems up, I probably shouldn't do that, as you and Lars and others point out.

What I'd suggest is some awareness campaign. With zypper, having Kernel:HEAD as a repository too is trivial, as is installing both kernels. "Want to help out? Boot into the kernel:head kernel and let us know how that goes." Systems that don't want to update but rather stick to the latest stable kernel - that is, my laptop ;-) - won't, but test environments might.

Maybe just have a Tumbleweed:Kernel repo that people can add to get this newer kernel if they want to be on even more of a bleading edge, that would like to the proper Kernel:HEAD release at the -rc5 time period. Perhaps that might balance the needs of users better?

Right, though I am not sure this is all that different from adding Kernel:HEAD as it is? Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/29/12 1:58 PM, Greg KH wrote:

On Wed, Aug 29, 2012 at 05:04:23PM +0200, Lars Marowsky-Bree wrote:

...

On 2012-08-28T06:46:46, Greg KH wrote:

...

On Tue, Aug 28, 2012 at 08:55:56AM +0200, Mike Galbraith wrote:

...

In practice, rc5 vs .0 probably won't make much difference at all, but more users will be bitten, else the move was a failure. So this move explicitly plans on users being bitten, detracting from Tumbleweed's rolling ~stable allure, _evading_ developmental regression detection and reporting duties being a major attractor to running rolling ~stable ;-)

That's a really good point. I guess I'm abusing my role here as both a kernel developer who wants to see stable kernels released by the community, and as the Tumbleweed maintainer, sorry about that.

I'm all for helping kernel.org developers out, but at the expense of people who are counting on Tumbleweed to not mess their systems up, I probably shouldn't do that, as you and Lars and others point out.

What I'd suggest is some awareness campaign. With zypper, having Kernel:HEAD as a repository too is trivial, as is installing both kernels.

"Want to help out? Boot into the kernel:head kernel and let us know how that goes."

Systems that don't want to update but rather stick to the latest stable kernel - that is, my laptop ;-) - won't, but test environments might.

...

Maybe just have a Tumbleweed:Kernel repo that people can add to get this newer kernel if they want to be on even more of a bleading edge, that would like to the proper Kernel:HEAD release at the -rc5 time period. Perhaps that might balance the needs of users better?

Right, though I am not sure this is all that different from adding Kernel:HEAD as it is?

Kernel:HEAD gets -rc1 updates from what I remember (note, this could be wrong), so yes, it is almost like that.

- -rc2 but I mentioned in another reply I'd have no problem pushing it at -rc1 instead if there's interest. I usually use -rc2 because there is a lot of stabilization that happens between the two. - -Jeff

And, as you point out, it's so close, that it probably doesn't help out much by me doing the extra work to wait until -rc5 to add the package to a different repo.

So, I think I'm going to back down from this proposal, and just leave things as they are. Jos and you and others rightly point out that Tumbleweed is supposed to be "stable", and by doing kernel updates at -rc5, just to get kernel testers to find problems, kind of goes against that original goal.

So, thanks to all for the feedback, and for the sanity check, I'll just leave things as-is and not change the way the kernel is being updated.

thanks,

greg k-h

- -- 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://www.enigmail.net/ iQIcBAEBAgAGBQJQPozVAAoJEB57S2MheeWyzQwQAJRGaiqie7NaDzu6R9tg41yQ UUE6jBzrY/NTCVQ45GFrrn0004sZ7TW8ZgPfog7T5OI+3V6DTn6K3pgULztooj4t sGMgVr1pPWuRKl20WXt1bpCYca87GTzbbmVhFInoZYvHHnQGuiPW7r+ki+t5zhpV bxONBsAzOZckw+YahemHVbmboRT7uJeDtcNYxMrR/oSgdmH4wnH653NBikarbD5K pbdTO5XfT1oxGhyTYVdJZOx9HI8/+0GHCm7UpWas682Uz5XZQrz51x4cc/tUY6QL QN3dIM+gV4e9Xts5faeak6gzYJs6eayVR070n3ygMjisQS/YASTqnVTKAPBtD5Zb hX25FTY/L7HjxOx0IX7tg9QhiR1zu/Ov64+afBlMS0ZpROnyUSlTNC49ywKmrC2N bYrQr9kIGbMI13ljli2CHlnTQHdI162FjHfj88YY/wkBL9xzI7k2jLKjnjsG1aON OZPXJCDBRIz835w4CHz3Pw1785w4ymK8sNVsC/hp0AAA8seLxJOqtUvedn3a7zO7 pwaz7bDhgfMweEir2BO872x27Z13CQ6s4L5iYTDYXADhO077zx+InL6tkZ1cgeiS w6jU3uXNDD6fYxGAnnIOQCN8k+ncQPCsahpx1/+jSSJl4qqvadEamAPaytmFhBMg XDz80qOyNYrj/LkuK8lj =aeoi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org