[opensuse-factory] Tumbleweed kernel changes to help upstream development
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? thanks, greg k-h -- 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: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? For example Firefox in its beta phase would be another candidate. I do not propose to do it. I do not even submit beta versions to Factory usually since I maintain a special OBS project for that purpose. Wolfgang -- 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 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?
For example Firefox in its beta phase would be another candidate. I do not propose to do it. I do not even submit beta versions to Factory usually since I maintain a special OBS project for that purpose.
Then I wouldn't suggest doing it for Firefox :) greg k-h -- 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 28 August 2012 06:05, Greg KH <gregkh@linux.com> 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
On Mon, Aug 27, 2012 at 10:15 PM, Andrew Wafaa <awafaa@opensuse.org> wrote:
On 28 August 2012 06:05, Greg KH <gregkh@linux.com> 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 <znmeb@znmeb.net> wrote:
On Mon, Aug 27, 2012 at 10:15 PM, Andrew Wafaa <awafaa@opensuse.org> wrote:
On 28 August 2012 06:05, Greg KH <gregkh@linux.com> 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 08/27/2012 10:05 PM, 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?
thanks,
greg k-h
I think this is perfectly sensible, given folks using Tumbleweed know going in they are getting new, lightly tested stuff. If those users, including myself are given ownership of testing which is/will be genuinely useful... then go for it. See you at LinuxCon, Peter -- 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 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 Tuesday, August 28, 2012 06:46:46 AM 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.
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
I would really prefer that Tumbleweed wasn't made more unstable by forcing people who want a stable-ish, up-to-date system to be the testers for the RC kernel releases. I would rather you have a different RC kernel repo so I can opt into it on a system that I don't rely on to get work done. I think that, that would be best. If there is a repo for that I will run it on some of my other systems but not on my Tumbleweed laptop that I use for work. 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, 2012-08-28 at 06:46 -0700, 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.
It's a worthy goal, just a question (as others have mentioned) of what Tumbleweed's primary mission is. Defining _how_ close to the edge a rolling ~stable distribution should get is rather a sticky wicket.
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?
Making kernel packages available in Tumbleweed and other stable bases sounds like a fine idea to me. That may be attractive to those who find bleeding edge everything (factory) to be far too much of an adventure. Recovering from a dud kernel is (generally) a walk in the park compared to userspace borkage. -Mike -- 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 <gregkh@linux.com> 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
On Wed, Aug 29, 2012 at 05:04:23PM +0200, Lars Marowsky-Bree wrote:
On 2012-08-28T06:46:46, Greg KH <gregkh@linux.com> 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. 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 -- 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 <gregkh@linux.com> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/28/2012 07:05 AM, Greg KH wrote:
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?
Hi, I have no objections to that. However I'm not sure how do you want to do it technically. Are you going to create a new Kernel:* project for that purpose? Since I don't think it's a good idea to put -rc kernels into Kernel:stable (and I would actually object to this). thanks, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQPG/JAAoJEL0lsQQGtHBJEEcP/AybfugavfYWq37QTjtaRDgR rFNxCwODR/QowVXSDR2KIr3jPGSaObsuFQm7DJIpcb06JtYzWvFjbHf5XDQC+zrO ZbV1J4ULMLCu8TN13wBvBH9N2HHIrk2cJLV8RpNaWC5zIcvAVeDk8Hn1U5EeP+fo jHQ42ZtDqmoPMSlURQo3hC3eFI+nmIQcN/1p6HhXT4qnmN+gpGrLO/qHOgZOlQJQ 84uTtS9XsDyzEY/l0dxFawAUoyvjVCK2KRXw2IgGHQ8Jt8bsLpp0z8TOHq6qNyDz EN4NGfuV6Gj719/PgH7HUWr8xNpkieDerAX1WoDJqkpMnQGA5EzOdXi6PsGSd7ka abZqe4E/S2ZrKr8pFrQodCShGQgzCWek4ouMXe4VHevWe7Wi6zi8JZKzQ3BWoyv7 GSr2+rwt+XYbGcf1pot408H0eRmJzMhQRA7BAVOWNPp7oJTEJ5F1Z2NHFJD0k9vP hvO7j0gui+sjFTEmc5YGpNlCdAQrHj5xGtTaLl1ccec1r+DjhT4ToO17/E6mQlLS 6Eru4/fGexQJ4f5zM/sgYbgSBKe1lNDg/VrOpc6Fgl4hFrUNf/yc3PKHnX+C/F6n XlbtRN+8bhrcgkOaQpWxpknh2z1qJIMgpgTVgbDYEKD0atgziVgOHcvSBddjPPs5 VpJCDBZFyidp1k3CaDse =Ul03 -----END PGP SIGNATURE----- -- 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 09:14:17AM +0200, Jiri Slaby wrote:
On 08/28/2012 07:05 AM, Greg KH wrote:
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?
Hi, I have no objections to that. However I'm not sure how do you want to do it technically. Are you going to create a new Kernel:* project for that purpose? Since I don't think it's a good idea to put -rc kernels into Kernel:stable (and I would actually object to this).
No, I would be linking to the kernels in Kernel:HEAD that Jeff creates, not create a new one. thanks, 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: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 28 August 2012 09:19, Lars Müller <lmuelle@suse.com> 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.²
Not since RPM 4.10.0 -> http://www.rpm.org/wiki/Releases/4.10.0#Generalbugfixesandenhancements ("Support dpkg-style sorting of tilde (~) in version/release") But sure, it's still not in openSUSE... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2012-08-28 10:29, Cristian Morales Vega wrote:
On 28 August 2012 09:19, Lars Müller <lmuelle@suse.com> 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.²
Not since RPM 4.10.0 -> http://www.rpm.org/wiki/Releases/4.10.0#Generalbugfixesandenhancements ("Support dpkg-style sorting of tilde (~) in version/release")
But sure, it's still not in openSUSE...
Check facts first. tilde-support is in openSUSE 12.2, backported from rpm-4.10 into our 4.9. -- 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 5:19 AM, Lars Müller <lmuelle@suse.com> 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, 2012-08-28 at 10:41 -0300, Claudio Freire wrote:
On Tue, Aug 28, 2012 at 5:19 AM, Lars Müller <lmuelle@suse.com> 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
That's actually not true: 3.6.0-rcX > 3.6.0-final (simply because r > f) zypper vcmp 3.6.0-final 3.6.0-rc1 3.6.0-final is older than 3.6.0-rc1 so is 3.6.0final or 3.6.0. The 'best' choice you can normally come up with will be along the lines of 3.4.99 or, as you will often also see, 3.4.99_3.5.0-rc1 (so 3.4.99 becomes the comparable version for rpm, and 3.5.0 at release time will always be 'larger'). RPM versioning can be confusing... zypper helps you in understanding it :) Dominique -- 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 <dimstar@opensuse.org> 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
On Monday, August 27, 2012 22:05:23 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?
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
thanks,
greg k-h
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
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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Achim Gratz <Stromeko@nexgo.de> [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 Mon, 27 Aug 2012 22:05:23 -0700 Greg KH <gregkh@linux.com> wrote:
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?
Any testing is as hard as the way out of trouble if something goes wrong. I see the point in having latest stable software on top of latest kernel as test bed and I can understand other people reluctance to expose their working machines to _unknown_ dangers. I was using Kernel:HEAD/KOTD for a whole year without problems that are worth to remember, so I don't think that testing RC kernels will bring noticeable increase in problems, comparing to chance of breakage in a whole stack of other software included in Tumbleweed. Additional repo as part of a solution is fine as it provides opt in way, but having setup and tool(s) that will simplify user interaction with test kernel can bring you more testers then separation of repos. For instance: * spare kernel that was working and that is still there when new one needs fallback. * change logs viewer, to see what is coming per user selected criteria; whole change log is too big to check every time on update. * easier bug reporting that enables half educated users to report bugs after falling back to working kernel. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (19)
-
Achim Gratz -
Andrew Wafaa -
Claudio Freire -
Cristian Morales Vega -
Dimstar / Dominique Leuenberger -
Drew Adams -
Greg KH -
Jan Engelhardt -
Jeff Mahoney -
Jiri Slaby -
Jos Poortvliet -
Lars Marowsky-Bree -
Lars Müller -
M. Edward (Ed) Borasky -
Mike Galbraith -
Patrick Shanahan -
Peter Linnell -
Rajko -
Wolfgang Rosenauer