Distro kernel update

Thorsten Leemhuis fedora at leemhuis.info
Fri Sep 2 10:55:23 UTC 2011


Hi!

Dave Jones wrote on 02.09.2011 00:24:
> On Thu, Sep 01, 2011 at 05:34:42PM -0400, Josh Boyer wrote:
>  > I will point out though that we continue to try and avoid deviation from
>  > upstream as much as possible.  Aside from fixes, there are really only a
>  > small handful of add-on patches in the Fedora kernels.  utrace and the
>  > i686 nx/execshield are the biggest and hopefully those also sort of go
>  > away.  Hopefully the _need_ for vanilla kernels is fairly small.
> Some of the lower hanging fruit got pushed again this cycle.
> When we move to 3.2, the fedora specific patches should be the smallest
> they've been in a long time.
> 
> (related: I'm tempted to remove all the vanilla stuff from the spec
> just to reduce some of the noise in there.  Any objections ?
> I think Roland was the only person who ever really used it)

Well, I actually really consider to offer prebuild vanilla kernels for
fedora in a repo (but until End of October I won't have time to start on
this) and the vanilla conditionals that are in the spec file right now
would make my life a lot easier afaics.

>  > > And does it really has to be that strict?
>  > Yes.  Staging drivers can be a huge timesink, particularly when users
>  > think they are getting something that will JUST WORK for their hardware
>  > and then it turns out to be a steaming pile of crap.

I understand that and agree for most of the staging drivers. But:

> Something worth pointing out, is that if there's enough demand from users
> for a specific driver to be cleaned up so we can support it, in some cases
> we may be in a position where we can task someone with that.
> We used to do a lot more of this sort of thing in the Red Hat Linux days
> than we have done in Fedora. 

Things like that is basically what I meant when I asked "does it really
has to be that strict?".

Another reason: The Hyper-V drivers in staging are still not perfect
afaics, but MS seems to be taking the job of improving them seriously
for some months now. Sure, there still plenty that can go wrong, but in
the current situation I'd say the benefits of shipping the drivers (and
thus making it easier for people to test) might be worth ignoring the
downsides.

>  > >  * Will updates like the one to 3.0/2.6.40 in F15 be considered normal
>  > > practice again for the future? Updates to latest kernel versions in the
>  > > latest Fedora release where nothing unusual in the past, but it always
>  > > bugged me that they happened to be so unpredictable (got way worse in
>  > > the past year afaics)t
>  > I'm guessing it will be normal practice, yes.  Being somewhat new here,
>  > I'm not sure why it fell out of practice.  Updating to the latest has a
>  > couple of factors involved with it, so it's not always a simple decision.
> I think f14 was the tail end of the "don't update the kernel because X will
> crap itself" problems. (Probably even sooner actually, but paranoia kept us
> on .35 forever).

Yeah, understood, Hopefully we can avoid similar problems in the future
right from the start.

> Going forward, I think it's pretty clear to see that it's worth continually moving
> just like we used to.  Yes we introduce new bugs every time, but we close out
> a lot more. The .40 update closed over a hundred bugs with little or no actual
> intervention on our part. (And probably more that just haven't retested/updated bz yet).
> Additionally being able to bug upstream with bugs on recent codebases instead
> of something from a year ago is invaluable.

Sounds really good, I'm all for it :-)

CU
 knurd


More information about the kernel mailing list