When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?

Thorsten Leemhuis fedora at leemhuis.info
Sat Jul 5 15:14:40 UTC 2008



On 05.07.2008 15:54, drago01 wrote:
> On Sat, Jul 5, 2008 at 2:56 PM, Thorsten Leemhuis <fedora at leemhuis.info> 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




More information about the kernel mailing list