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

[Thorsten Leemhuis]

On 05.07.2008 17:22, drago01 wrote:
> On Sat, Jul 5, 2008 at 5:14 PM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>>
>> 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.
> 
> 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