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
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
> > * Will updates like the one to 3.0/2.6.40 in F15 be
> > 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
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 :-)