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