Distro kernel update

[Thorsten Leemhuis]

Hi!

Josh Boyer wrote on 01.09.2011 23:34:
> On Thu, Sep 01, 2011 at 10:33:34PM +0200, Thorsten Leemhuis wrote:
>> 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 :).

Thanks for your answers!

>>  * 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'll try to find time for that.

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

Yeah, understood and known, but I still have the feeling a lot of
upstream maintainers will tell people to try vanilla kernels before they
start listing at bug reports at all (and utrace and the nx stuff iirc in
the past were responsible for some odd bugs in other areas but [maybe
I'm wrong with that], so that demand is not completely unreasonable afaics)

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

/me will write something in the reply to davej's mail

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

+1

> [...]
>>  * 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.

But I assume you wouldn't mind to much if someone would knowingly ignore
2 and 3 and set such a repo up somewhere to see if people would use it?

CU
 knurd