Re: [opensuse-kernel] HEAD rebased to 2.6.26-rc5-git5
On Wed, Jun 18, 2008 at 11:18:56AM +0200, Pavel Machek wrote:
Hi!
Just a quick FYI that after the 11.0 branch announcement, the HEAD kernel has been rebased to 2.6.26-rc5-git5. Updates will be ongoing.
Thanks a lot for doing this.
Once 11.0 is officially released, this will be updated as the FACTORY kernel. Until then, packages will be available via the KOTD site at http://ftp.suse.com/pub/projects/kernel/kotd/HEAD/
I'm considering what would be involved in updating the version that is in the "normal" 11.0 update repos to 2.6.26, when it is out and we seem to have tested it pretty well in FACTORY. It would be nice to offer this for the increased number of bug fixes, and new hardware support. But it would be something new from what we have done before, and I don't know how people would react to it.
Any opinions?
I believe it is 'too dangerous'. We tested 2.6.25 in betas and rcs, while 2.6.26 would be just dumped to users.
With some testing first of course :)
OTOH, having easy way of installing 2.6.26 _in addition_ to 2.6.25 kernel would be nice ...
I guess adding 2.6.26 into boot menu as an non-default option by update would be acceptable compromise?
That sounds fine to me. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Why not have a different repo for this? Other distros have a
"volatile" repo for fast changes, why not offer that as an option...
Something between the release and FACTORY.
-Jeff
--
Jeff Mahoney (mobile)
SUSE Labs
On Jun 19, 2008, at 8:27 PM, Greg KH
On Wed, Jun 18, 2008 at 11:18:56AM +0200, Pavel Machek wrote:
Hi!
Just a quick FYI that after the 11.0 branch announcement, the HEAD kernel has been rebased to 2.6.26-rc5-git5. Updates will be ongoing.
Thanks a lot for doing this.
Once 11.0 is officially released, this will be updated as the FACTORY kernel. Until then, packages will be available via the KOTD site at http://ftp.suse.com/pub/projects/kernel/kotd/HEAD/
I'm considering what would be involved in updating the version that is in the "normal" 11.0 update repos to 2.6.26, when it is out and we seem to have tested it pretty well in FACTORY. It would be nice to offer this for the increased number of bug fixes, and new hardware support. But it would be something new from what we have done before, and I don't know how people would react to it.
Any opinions?
I believe it is 'too dangerous'. We tested 2.6.25 in betas and rcs, while 2.6.26 would be just dumped to users.
With some testing first of course :)
OTOH, having easy way of installing 2.6.26 _in addition_ to 2.6.25 kernel would be nice ...
I guess adding 2.6.26 into boot menu as an non-default option by update would be acceptable compromise?
That sounds fine to me.
thanks,
greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Jun 20, 2008 at 12:18:42AM -0400, Jeff Mahoney wrote:
Why not have a different repo for this? Other distros have a "volatile" repo for fast changes, why not offer that as an option... Something between the release and FACTORY.
... we have the openSUSE buildservice :) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Jun 19, 2008 at 05:27:33PM -0700, Greg KH wrote:
On Wed, Jun 18, 2008 at 11:18:56AM +0200, Pavel Machek wrote:
Hi!
Just a quick FYI that after the 11.0 branch announcement, the HEAD kernel has been rebased to 2.6.26-rc5-git5. Updates will be ongoing.
Thanks a lot for doing this.
Once 11.0 is officially released, this will be updated as the FACTORY kernel. Until then, packages will be available via the KOTD site at http://ftp.suse.com/pub/projects/kernel/kotd/HEAD/
I'm considering what would be involved in updating the version that is in the "normal" 11.0 update repos to 2.6.26, when it is out and we seem to have tested it pretty well in FACTORY. It would be nice to offer this for the increased number of bug fixes, and new hardware support. But it would be something new from what we have done before, and I don't know how people would react to it.
Any opinions?
I believe it is 'too dangerous'. We tested 2.6.25 in betas and rcs, while 2.6.26 would be just dumped to users.
With some testing first of course :)
No way. Thats what the BETA and RC phase was for, we cannot do this for the released product.
OTOH, having easy way of installing 2.6.26 _in addition_ to 2.6.25 kernel would be nice ...
I guess adding 2.6.26 into boot menu as an non-default option by update would be acceptable compromise?
That sounds fine to me.
But this will be very difficult to do and error prone. :( Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Jun 20, 2008 at 03:51:46PM +0200, Marcus Meissner wrote:
I believe it is 'too dangerous'. We tested 2.6.25 in betas and rcs, while 2.6.26 would be just dumped to users.
With some testing first of course :)
No way. Thats what the BETA and RC phase was for, we cannot do this for the released product.
So, you are saying that the kernel developer community doesn't test their kernel releases enough for you? :) What would you like the kernel developers to do in order for you to feel better about doing exactly what Fedora does here (remember, they have more users and they do this all the time...)
OTOH, having easy way of installing 2.6.26 _in addition_ to 2.6.25 kernel would be nice ...
I guess adding 2.6.26 into boot menu as an non-default option by update would be acceptable compromise?
That sounds fine to me.
But this will be very difficult to do and error prone. :(
Why? It shouldn't be that hard to tell the bootloader to not mark this kernel as the main one to install. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Am Samstag, 21. Juni 2008 schrieb Greg KH:
On Fri, Jun 20, 2008 at 03:51:46PM +0200, Marcus Meissner wrote:
I believe it is 'too dangerous'. We tested 2.6.25 in betas and rcs, while 2.6.26 would be just dumped to users.
With some testing first of course :)
No way. Thats what the BETA and RC phase was for, we cannot do this for the released product.
So, you are saying that the kernel developer community doesn't test their kernel releases enough for you? :)
Greg, what Marcus is saying here, is that average kernel developers are bad in tracking userspace changes. They throw the new kernels on their systems and watch what broke, fixing it silently or not not at all, if that subsystem isn't too important for them. They're used to break some functionality from their systems on a regular basis. And you would only note the breakage, if the affected subsystem is essential for them AND no fix/workaround is available somewhere in the deep space of OS. On the contrary, take the average user of a high level distro like openSUSE. If things break on their system out of the deep blue, they usually don't have any idea, what broke - is it the kernel, userspace, some config magic badly chiming in, what ever, they're unable to locate the breakage other then - my wlan doesn't work anymore, bluetooth headset dysfunctional, no UI (aka X) and so on. While I occasionally want newer kernels for certain reasons, the switch is often painful - e.g. my notebook had a iwl4965 based wlan card with openSUSE 10.2, and I've upgraded the kernel to 2.6.24.4. I was unable to get wlan to work again in an acceptable timeframe (was on holiday, didn't tested that subsystem after upgrade). YaST didn't cope with the new infrastructure, but adjusting stuff manually was just too painful - starting from firmware, it would have included to upgrade a lot of userspace - with references back to kernel space (madwifi), that was where I lost interest.. (aka pain was stronger than the outcome). The problem, I see here, is even the _released_ product contains an awful amount of glitches still - and fixing them is unpossible, if you change too many values in the equation at once..
What would you like the kernel developers to do in order for you to feel better about doing exactly what Fedora does here (remember, they have more users and they do this all the time...)
I fear, that the kernel developers aren't able to do anything in this respect, unless changesets from release to release shrink _immensely_. It would take a tremendous effort of something like a test center, with lots of human and hardware resources to test all the permutations that are possible then in loads of different environments (and no, kernel compile testing of random configs is not enough). Note, it is a general difference in using a computer system from day to day in the usual kernel developer way, which exercises mostly the main paths of IO, standard FS, MM, etc compared to those systems running in the wild, used creatively with always changing environments and hardware.
OTOH, having easy way of installing 2.6.26 _in addition_ to 2.6.25 kernel would be nice ...
I guess adding 2.6.26 into boot menu as an non-default option by update would be acceptable compromise?
That sounds fine to me.
But this will be very difficult to do and error prone. :(
Why? It shouldn't be that hard to tell the bootloader to not mark this kernel as the main one to install.
To complete the already too long message, may I remember you, that me as a single user suffer from major problems, a few days after rollout of 11.0 to 3 selected systems here - regressions to things used to work before: - Bug 401119 - ntp doesn't work with serial DCF receiver - Bug 401730 - gphoto2 capture causes usb disconnect and subsequently a kernel crash and apart from Bug 401259 - libzypp duplicates gpg keys in the database, this distribution feels great, so far! But I didn't upgrade my main system, yet. Imagine, what happens, if I would rollout that distribution to say 50 systems - all with different hardware, capabilities, and usage profiles. That's impossible at the moment, since daytime is fixed, and I still have to support my family, too. And now, you try to throw in another kernel - which I do understand form a certain perspective, but I fear, I'm unable to ever get into a stable state here (which I need, since the operation system is the basis of my day to day work, not the work itself, at least most of my time). Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:
On Fri, Jun 20, 2008 at 03:51:46PM +0200, Marcus Meissner wrote:
I believe it is 'too dangerous'. We tested 2.6.25 in betas and rcs, while 2.6.26 would be just dumped to users. With some testing first of course :) No way. Thats what the BETA and RC phase was for, we cannot do this for the released product.
So, you are saying that the kernel developer community doesn't test their kernel releases enough for you? :)
Marcus is right, that's what the beta and RC phases are for. Suddenly integrating a new kernel mid-release ends up negating all that work. As Hans-Peter mentioned at length, the kernel itself may not be buggy but interactions with the rest of the system may have changed, with unintended consequences.
What would you like the kernel developers to do in order for you to feel better about doing exactly what Fedora does here (remember, they have more users and they do this all the time...)
I'm not really concerned with what Fedora does. They also have a reputation of being bleeding edge. Citing more users doesn't really back an argument, but if you want to go down that path, look at Ubuntu. We have the advantage of offering the best of both worlds. Users can stick with a release track with minimal updates outside of security and data corruption with openSUSE 11.0 or they can point to the Factory repository instead and always get the latest and greatest. They can even choose when to switch to the latest and greatest without having it forced down their throats. I wouldn't mind offering a third repository for kernels, something along the lines of what I was trying to do during the 11.0 alpha cycle. We'd keep updating the kernel CVS as we do now, but when there is a point release, it will save that one as a "stable" kernel while we move on to newer RCs. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkhdWNMACgkQLPWxlyuTD7LQDQCfePWQ8jTIetvMRZQ+nXTkLqMt jV4AnRY2X/hMI55oyur4+WOGBij1k9In =adkH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Jun 20, 2008 at 08:42:38PM -0700, Greg KH wrote:
On Fri, Jun 20, 2008 at 03:51:46PM +0200, Marcus Meissner wrote:
I believe it is 'too dangerous'. We tested 2.6.25 in betas and rcs, while 2.6.26 would be just dumped to users.
With some testing first of course :)
No way. Thats what the BETA and RC phase was for, we cannot do this for the released product.
So, you are saying that the kernel developer community doesn't test their kernel releases enough for you? :)
What would you like the kernel developers to do in order for you to feel better about doing exactly what Fedora does here (remember, they have more users and they do this all the time...)
This is more a question to pose to Coolo or Michael Loeffler. We do at least Beta testing against our users during the development cycle of several months. Suspend to anything ... breaks models or does not break models... Wireless testing ... Any kind of userland interaction. I really wonder that Fedora is not falling on their noses with this. And we are different from Fedora. ;)
OTOH, having easy way of installing 2.6.26 _in addition_ to 2.6.25 kernel would be nice ...
I guess adding 2.6.26 into boot menu as an non-default option by update would be acceptable compromise?
That sounds fine to me.
But this will be very difficult to do and error prone. :(
Why? It shouldn't be that hard to tell the bootloader to not mark this kernel as the main one to install.
Have you ever seen the perl-Bootloader bugs? We had like 200+ of them sinc SUSE Linux 10.1 ... This piece of "code" would be involved here, and I do not trust it. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (4)
-
Greg KH -
Hans-Peter Jansen -
Jeff Mahoney -
Marcus Meissner