Distro kernel update

[Josh Boyer]

On Thu, Sep 01, 2011 at 10:33:34PM +0200, Thorsten Leemhuis wrote:
> Hi!
> 
> On 01.09.2011 15:44, Josh Boyer wrote:
> > It's been a while since we gave an overview of the kernel plans for
> > Fedora, so I thought I'd send a brief update on what we're doing, where
> > we're headed, and why.
> > [...] 
> > So there's a brief overview of the kernel happenings going on in Fedora.
> > If you have questions, feel free to shoot an email to the fedora kernel
> > list!
> 
> A few questions spring to my mind:

I'll give my personal answers.  If Dave or Chuck disagree, I'm sure
they''ll do so publicly :).

>  * there were a few attempts and discussions to ship vanilla kernels in
> separate repos or even directly in the Fedora repositories. I assume you
> guys (or anybody else on this list) don't have time or interest in renew
> those efforts? I sometimes think they might be handy to have, as it
> would make statements like "please try the latest vanilla rpm; if it
> does not work there try to bug upstream about it directly, as we in
> Fedora likely won't come down to fix this individual bug, because it's a
> very specific problem that bugs only very few people" possible.

I was doing that a long time ago and uploading them to my fedorapeople
account.  I don't have a ton of time to do that right now, but it might
be worthwhile for someone to do builds of major releases (3.0, 3.1) for
vanilla to have them handy.  Volunteers for that gladly accepted.

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.

>  * how long will this continue to be a draft?
> http://fedoraproject.org/wiki/KernelStagingPolicy

No longer.  It's been the defacto policy for a while now.  Draft is
removed.

> 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.

>  * 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 hope going forward that we're a bit more communicative with our plans.
That's kind of why I sent my original email today.

>  * if updates to latest kernel versions become normal again, wouldn't it
> be a good idea to set up a repo that contains the latest rc kernels for
> the latest Fedora release? Maybe a few people that (for example) run F15
> now might be interested interested and improving the 3.1/2.6.41 packages
> before they hit updates-testing once 3.1 got released.

There's a few downsides to doing that:

1) Time

2) Multiplying the kernels out there

3) Potentially pulling testers off of Branched/Rawhide just because
their only interested in the kernel.  We have a hard enough time getting
people to test Branched/Rawhide as it is, so personally I'm not keen on
making that even more prevelant.

4) Going with 3 above, we tend to wait until a kernel is somewhat
'proven' in the newest release before pulling it into something stable.

josh