Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On Tue, Aug 05, 2008 at 05:05:33PM -0400, Chuck Ebbert wrote: John W. Linville wrote: I still think that for continuity's sake f8 and f9 should continue to get wireless fixes from 2.6.27. Those should only be specific bug fixes (although I suppose there is still time for a new driver), so hopefully the nattering nabobs won't be opposed to continuing with that part of the original plan. If you push wireless fixes to -stable Fedora would then get them for free. I don't see many wireless patches in there generally, though the ath5k memory corruption fix just went in. Well I see where you had to revert a few in the F-9 changelogs as you rebased on later -stable kernels, so there must be a few getting through. :-) If you would like to nominate more wireless fixes for -stable, feel free to do so. As it is, I mostly rely on my driver/stack maintainers to identify appropriate patches for stable -- they are aware of the process, including the Cc: [EMAIL PROTECTED] trick. Even so, that only works for those problems which date back to 2.6.26. Since Fedora kernels already have 2.6.27 code, then the 2.6.27 patches would seem appropriate for Fedora too. Of course you could elide the 2.6.27 code from the Fedora kernels as you have suggested elsewhere, but then you will reintroduce other problems. And new drivers would be great. Lots of people seem to want ath9k, for example. We'll see. Honestly I've been dropping other things in favor of keeping Fedora up-to-date for the last year or more. Rather than find ways to spend just as much time on Fedora while getting less bang for my buck, I'll probably find something else to occupy more of my time. In particular, I think ath9k will make it into the 2.6.27 queue. John -- John W. Linville [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
John W. Linville wrote: I still think that for continuity's sake f8 and f9 should continue to get wireless fixes from 2.6.27. Those should only be specific bug fixes (although I suppose there is still time for a new driver), so hopefully the nattering nabobs won't be opposed to continuing with that part of the original plan. If you push wireless fixes to -stable Fedora would then get them for free. I don't see many wireless patches in there generally, though the ath5k memory corruption fix just went in. And new drivers would be great. Lots of people seem to want ath9k, for example. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On Tue, Aug 05, 2008 at 05:05:33PM -0400, Chuck Ebbert wrote: John W. Linville wrote: I still think that for continuity's sake f8 and f9 should continue to get wireless fixes from 2.6.27. Those should only be specific bug fixes (although I suppose there is still time for a new driver), so hopefully the nattering nabobs won't be opposed to continuing with that part of the original plan. If you push wireless fixes to -stable Fedora would then get them for free. I don't see many wireless patches in there generally, though the ath5k memory corruption fix just went in. And new drivers would be great. Lots of people seem to want ath9k, for example. John has been forwarding me fixes, I just haven't gotten around to applying them yet. Will do so tonight. r, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On Mon, Jul 07, 2008 at 11:37:10AM -0400, John W. Linville wrote: So, here is what I propose: -- continue the current practice until 2.6.26 is released and the 2.6.27 merge window closes; -- after that, continue the current practice for updating rawhide; but, -- once F9 (and presumably F8) move to 2.6.26, move the -pending bits to the -wireless.patch and do _not_ create a new -pending.patch for 2.6.28 bits; -- once 2.6.27 is released, drop the -wireless patch and F9/F8 will get no more wireless updates at all; -- F10 will release with -wireless and -pending patches inherited from rawhide, but they will age out following the process described for F9/F8 above. Sorry to revive an old thread, but I'd like to amend the plan. I'm going to decline to add any post-2.6.27 wireless bits to rawhide. I think continuing that practice only complicates things for when rawhide becomes f10, and in the meantime just adds to my personal pain. Besides, I'm quite tired of...well, I'm just tired. I'm prepared to consider adding specific items as requested (e.g. ath9k), but for now let's just presume that rawhide will mostly just get its wireless bits through Linus. I still think that for continuity's sake f8 and f9 should continue to get wireless fixes from 2.6.27. Those should only be specific bug fixes (although I suppose there is still time for a new driver), so hopefully the nattering nabobs won't be opposed to continuing with that part of the original plan. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On Sat, Jul 05, 2008 at 02:56:30PM +0200, Thorsten Leemhuis wrote: John (CCed), I really appreciate your work in the wireless area and would like to use the opportunity to say thanks for all you work, as support for WLAN hardware in the Linux kernel improved a lot in the upstream kernel and Fedora thx to your (and other linux wireless developers) work over the last two years. Thanks. Normally my reward is to be kicked in the teeth when something breaks -- usually by the same people who would be screaming but this is already fixed upstream if I didn't push very recent patches, but I digress... But we now for at least the second time in the past few weeks had/have a more-than-minor wireless breakage in a Fedora kernel for a released distro (bug #453390 now; http://lwn.net/Articles/286558/ is discussing the one some weeks ago; I think there was one more breakage not that long ago, but I can't remember). I and many users (see for example #453390) got hit by those problems. That's why I was wondering: what are we at Fedora doing to prevent similar problems in the future? For the record, bug 453390 was caused by me screwing-up a fixup for build breakage between the current wireless code and the base 2.6.25 kernel in F9. In other words, this was not the result of merging some buggy upstream patch. Instead it was the result of simple human error on my part. I would also point-out that cherry-picking individual fixes often means rebasing that fix between upstream and the target kernel, and doing so creates an opportunity for such human error mistakes to creep-in _with_every_single_fix_. If we want to cherry-pick individual wireless LAN fixes into Fedora kernels then we need another monkey. I already spend more time than I should spare keeping Fedora kernels up-to-date as it is. But all the smiling faces are my reward... Three things spring to my mind and I just propose then here for discussion; maybe something good comes out of it in the end: - a karama of +3 in bodhi seems not enough for a auto-move from testing to stable (or even worse: straight to stable if enough people tested the kernel and gave their +1 after the update got filed in bodhi but *before* it actually hit fedora-testing) if there are no other pressing issues (like security fixes). The kernel is a to complex beast; more then 3 people should be needed to give a +1. And a bit of time needs to pass to give enough people the opportunity to install, test and report problems with new kernels. For the latest kernel it seems to me that to less time really was the problem, otherwise the problem from #453390 would have been noticed earlier Something is definitely broken here. I seem to recall beating the drum for Karma in the not-too-distant past, when the required number seemed to be up in the teens? Who's bright idea was it to bring this value down to +3? My assumption had been that it was okay to push these wireless bits because Bodhi would keep us from releasing truly broken kernels. If we are going to use +3 then my assumption is clearly wrong and my practices have to change. - should we separate security updates and other kernel fixes in a better way to make sure those other fixes get proper testing before they get send out to the users? Sounds good, but I have no idea how to do that. Does Fedora need a z-stream a la RHEL? - John, having all those pending and not-yet-upstream-merged improvements for wireless hardware in the Fedora kernel was something good in the past when WLAN support in the kernel was quite bad/incomplete. But the main and most important bits for proper wireless hardware support seem to be in the upstream kernel now; sure, there will always be improvements in the queue, but that's the same in most other linux subsystems with drivers as well. So I'm wondering: isn't it time now to finally stop shipping all those wireless-next bits (currently quite some big patches; see: -rw-rw-r-- 1 thl thl2484 14. Mär 17:06 linux-2.6-ms-wireless-receiver.patch -rw-rw-r-- 1 thl thl 39874 4. Jul 22:21 linux-2.6-wireless-fixups.patch -rw-rw-r-- 1 thl thl 2656652 4. Jul 22:21 linux-2.6-wireless-pending.patch -rw-rw-r-- 1 thl thl 4165718 4. Jul 22:21 linux-2.6-wireless.patch ) in released Fedora Version (e.g. 8 and 9 currently) when we start shipping 2.6.26? Perhaps it is worth explaing a bit about what these are: -- linux-2.6-wireless.patch contains the stream of wireless patches going from the base kernel's release (currently 2.6.25) and the next upstream release (currently 2.6.26); -- linux-2.6-wireless-pending.patch contains the stream of wireless patches from the next upstream release to the following release (currently 2.6.27); -- linux-2.6-wireless-fixups.patch contains the changes required to un-break the build after applying the previous two patches (a screw-up here caused bug 453390). So if you dropped the -wireless patch (i.e. the
When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
Hi all John (CCed), I really appreciate your work in the wireless area and would like to use the opportunity to say thanks for all you work, as support for WLAN hardware in the Linux kernel improved a lot in the upstream kernel and Fedora thx to your (and other linux wireless developers) work over the last two years. But we now for at least the second time in the past few weeks had/have a more-than-minor wireless breakage in a Fedora kernel for a released distro (bug #453390 now; http://lwn.net/Articles/286558/ is discussing the one some weeks ago; I think there was one more breakage not that long ago, but I can't remember). I and many users (see for example #453390) got hit by those problems. That's why I was wondering: what are we at Fedora doing to prevent similar problems in the future? Three things spring to my mind and I just propose then here for discussion; maybe something good comes out of it in the end: - a karama of +3 in bodhi seems not enough for a auto-move from testing to stable (or even worse: straight to stable if enough people tested the kernel and gave their +1 after the update got filed in bodhi but *before* it actually hit fedora-testing) if there are no other pressing issues (like security fixes). The kernel is a to complex beast; more then 3 people should be needed to give a +1. And a bit of time needs to pass to give enough people the opportunity to install, test and report problems with new kernels. For the latest kernel it seems to me that to less time really was the problem, otherwise the problem from #453390 would have been noticed earlier - should we separate security updates and other kernel fixes in a better way to make sure those other fixes get proper testing before they get send out to the users? - John, having all those pending and not-yet-upstream-merged improvements for wireless hardware in the Fedora kernel was something good in the past when WLAN support in the kernel was quite bad/incomplete. But the main and most important bits for proper wireless hardware support seem to be in the upstream kernel now; sure, there will always be improvements in the queue, but that's the same in most other linux subsystems with drivers as well. So I'm wondering: isn't it time now to finally stop shipping all those wireless-next bits (currently quite some big patches; see: -rw-rw-r-- 1 thl thl2484 14. Mär 17:06 linux-2.6-ms-wireless-receiver.patch -rw-rw-r-- 1 thl thl 39874 4. Jul 22:21 linux-2.6-wireless-fixups.patch -rw-rw-r-- 1 thl thl 2656652 4. Jul 22:21 linux-2.6-wireless-pending.patch -rw-rw-r-- 1 thl thl 4165718 4. Jul 22:21 linux-2.6-wireless.patch ) in released Fedora Version (e.g. 8 and 9 currently) when we start shipping 2.6.26? Just my 2 cent. Cu knurd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On Sat, Jul 5, 2008 at 2:56 PM, Thorsten Leemhuis [EMAIL PROTECTED] wrote: - a karama of +3 in bodhi seems not enough for a auto-move from testing to stable (or even worse: straight to stable if enough people tested the kernel and gave their +1 after the update got filed in bodhi but *before* it actually hit fedora-testing) if there are no other pressing issues (like security fixes). The kernel is a to complex beast; more then 3 people should be needed to give a +1. And a bit of time needs to pass to give enough people the opportunity to install, test and report problems with new kernels. Well the problem is not the patches that are being shipped but bodhi. Auto pushing for something like the kernel should be disabled, to prevent such stuff from happening. The bug you are referring to, has been resolved quickly, if the kernel stayed in testing (ie no autopush) it would not have hit stable with this bug.(same for other, non wireless related issues). ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On 05.07.2008 15:54, drago01 wrote: On Sat, Jul 5, 2008 at 2:56 PM, Thorsten Leemhuis [EMAIL PROTECTED] wrote: - a karama of +3 in bodhi seems not enough for a auto-move from testing to stable (or even worse: straight to stable if enough people tested the kernel and gave their +1 after the update got filed in bodhi but *before* it actually hit fedora-testing) if there are no other pressing issues (like security fixes). The kernel is a to complex beast; more then 3 people should be needed to give a +1. And a bit of time needs to pass to give enough people the opportunity to install, test and report problems with new kernels. Well the problem is not the patches that are being shipped but bodhi. Yes and no. The patches are quite big and carry a additional risk. We don't take such risk in other areas (Sound, LAN, Storage -- there for similar reasons it might make sense) -- so why should we take that risk for WLAN drivers in stable releases (might be something else for rawhide now and then)? There was a reasons until now (upstream sucked until a few months ago), but we IMHO have to stop that sooner or later (otherwise Alsa maintainers, Jeff G./Alan Cox might want to do the same and then it really becomes problematic). As the most important WLAN bits are in the kernel now with 2.6.26 it's IMHO a good time to think about slowing down a bit. Of cause we can still cherry picking some improvements if we want. Auto pushing for something like the kernel should be disabled, to prevent such stuff from happening. The bug you are referring to, has been resolved quickly, if the kernel stayed in testing (ie no autopush) it would not have hit stable with this bug.(same for other, non wireless related issues). Well, that is round about what I said in my discussion point just in slightly different words ;-) Cu knurd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On Sat, Jul 5, 2008 at 5:14 PM, Thorsten Leemhuis [EMAIL PROTECTED] wrote: On 05.07.2008 15:54, drago01 wrote: On Sat, Jul 5, 2008 at 2:56 PM, Thorsten Leemhuis [EMAIL PROTECTED] wrote: - a karama of +3 in bodhi seems not enough for a auto-move from testing to stable (or even worse: straight to stable if enough people tested the kernel and gave their +1 after the update got filed in bodhi but *before* it actually hit fedora-testing) if there are no other pressing issues (like security fixes). The kernel is a to complex beast; more then 3 people should be needed to give a +1. And a bit of time needs to pass to give enough people the opportunity to install, test and report problems with new kernels. Well the problem is not the patches that are being shipped but bodhi. Yes and no. The patches are quite big and carry a additional risk. We don't take such risk in other areas (Sound, LAN, Storage -- there for similar reasons it might make sense) -- so why should we take that risk for WLAN drivers in stable releases (might be something else for rawhide now and then)? There was a reasons until now (upstream sucked until a few months ago), but we IMHO have to stop that sooner or later (otherwise Alsa maintainers, Jeff G./Alan Cox might want to do the same and then it really becomes problematic). As the most important WLAN bits are in the kernel now with 2.6.26 it's IMHO a good time to think about slowing down a bit. Of cause we can still cherry picking some improvements if we want. Well if the upstream maintainer sees a need for this why not? (given the changes go to testing first) Auto pushing for something like the kernel should be disabled, to prevent such stuff from happening. The bug you are referring to, has been resolved quickly, if the kernel stayed in testing (ie no autopush) it would not have hit stable with this bug.(same for other, non wireless related issues). Well, that is round about what I said in my discussion point just in slightly different words ;-) Well this is because we agree here ;) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On 05.07.2008 17:22, drago01 wrote: On Sat, Jul 5, 2008 at 5:14 PM, Thorsten Leemhuis [EMAIL PROTECTED] wrote: On 05.07.2008 15:54, drago01 wrote: On Sat, Jul 5, 2008 at 2:56 PM, Thorsten Leemhuis [EMAIL PROTECTED] wrote: - a karama of +3 in bodhi seems not enough for a auto-move from testing to stable (or even worse: straight to stable if enough people tested the kernel and gave their +1 after the update got filed in bodhi but *before* it actually hit fedora-testing) if there are no other pressing issues (like security fixes). The kernel is a to complex beast; more then 3 people should be needed to give a +1. And a bit of time needs to pass to give enough people the opportunity to install, test and report problems with new kernels. Well the problem is not the patches that are being shipped but bodhi. Yes and no. The patches are quite big and carry a additional risk. We don't take such risk in other areas (Sound, LAN, Storage -- there for similar reasons it might make sense) -- so why should we take that risk for WLAN drivers in stable releases (might be something else for rawhide now and then)? There was a reasons until now (upstream sucked until a few months ago), but we IMHO have to stop that sooner or later (otherwise Alsa maintainers, Jeff G./Alan Cox might want to do the same and then it really becomes problematic). As the most important WLAN bits are in the kernel now with 2.6.26 it's IMHO a good time to think about slowing down a bit. Of cause we can still cherry picking some improvements if we want. Well if the upstream maintainer sees a need for this why not? (given the changes go to testing first) In rawhide -- sure, let them do that as long as we are not close to a release. That's what rawhide is for. But kernel updates for a stable/release Fedora version should IMHO normally not contain big and frequently changing/updated development patchsets. Or, to abuse some words from someone else in the discussions around separately packaged kernel modules for Fedora: If they [the patches in this case] are not good enough to get applied upstream why should they be good enough for us? There is a reason for the short merge window and the longer stabilization phase upstream. Cu knurd ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
