On 07.07.2008 18:51, Dave Jones wrote:
On Mon, Jul 07, 2008 at 12:30:28PM -0400, Jeremy Katz wrote:
> > -- 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;
> This sounds reasonable. And to be fair, they will get wireless updates,
> but only when they get other drivers (eg, by going to 2.6.28) or things
> that are small and pushed to -stable upstream
Yeah, this proposal makes a lot of sense to me.
+1, as that's round about one of the things I suggested in my mail ;-)
Just one additional comment to the mail from John:
> 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.
None of the patches in question meet this definition.
We misunderstood us here. ;-)
They are all
queued for upstream. Some of them are queued for the next upstream
release rather than the current one due mostly to the upstream release
process's scheduling requirements. [...]
And that is actually what I meant. Upstream doesn't take them *now*, as
it's considered to risky for upstream now, as upstream has a
stabilization phase. So if it's to risky for them, then it's IMHO to
risky for us in a stable update as well.
CU
knurd
P.S.: For those interested, David Nielsen has a blog entry related to
this discussion:
http://davidnielsen.wordpress.com/2008/07/06/pushing-kernels-more-aggressively-to-updates-testing/
David Nielsen: Pushing kernels more aggressively to updates-testing
On thing struck me tonight about the recent fiasco relating to the
stable marking of a kernel that just happened to also kill wifi for a
great number of users. We did the correct thing, to a degree naturally,
the update was in relation to a security update something Fedora takes
very seriously. As such our users should always feel safe knowing that
we will push such updates fast, keeping their systems secure through
multiple means including proactive security and rapid updates.
However the problem is that we don’t apply the update to the existing
stable kernel, the patch is always applied on top of the progressing
kernel, meaning we also end up shipping a lot of other things such as
bugfixes, updates to the latest upstream STABLE tree and various other
things. This however is confronted with one problem, the kernels in
between the current stable and next update are not all being pushed to
updates-testing - only selected kernel updates are. In cases where we
then have to release a security fix we are forced to ship a bunch of
stuff additionally which is not likely to have been tested extensively.
It occures to me that catching these bugs before they become a problem
for average users could be accompliced by making better use of
updates-testing, testers are normally willing to experience a degree of
breakage and are qualified to file bugs for the most part. Then at least
when an urgent update is required we will not likely be surprised by
massive unrelated breakage - it might still occure but we can warn
people if avoiding massive breakage is impossible and reverting the
offending patches is impossible prior to release.
An additional problem caused by this is that when an urgent release
contains bugs we will be urged to ship another update straight
afterwards. Opening us to even more bugs from another untested delta
(since other development is likely to have gone on along side the
bugfix) and having our users suck down a second kernel package shortly
after the original update.
The other option would be applying the security update to the current
stable kernel and not carrying the current delta in the update, but this
is expensive in terms of man power and time, it also goes counter to the
rapidly developing nature of Fedora in general. This is the realm of the
enterprise distros, if people want this approach something like
RHEL/CentOS is likely a better fit for them.
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
