[fab] Non-standard kernels in the Fedora Multiverse

Tim Burke tburke at redhat.com
Tue May 9 02:33:56 UTC 2006


Tom 'spot' Callaway wrote:
> On Mon, 2006-05-08 at 15:53 -0400, Greg DeKoenigsberg wrote:
>
>   
>> 1. If it's okay for RH to put nonstandard kernels into Fedora, then 
>> shouldn't it be okay for the community to put nonstandard kernels into 
>> Fedora?  If not, why not?
>>     
>
> I think the reasons why we don't want to do this have been made quite
> clear. Its a maintenance nightmare. I already told the OpenVZ folks that
> we couldn't have a "VZ enabled" kernel package in Fedora unless it went
> into upstream (or they could convince Dave Jones to include it in his
> SRPM).
>
>   
Just to share some exposure into what it takes to keep a non-standard 
kernel working in the Fedora tree:
- Pretty much a full-time dedicated highly experienced kernel developer 
to spend the vast majority of their time playing patch monkey to keep up 
with the high rate of upstream change.  We have someone doing this role 
for Xen and its more than a fulltime job.  Same thing would have to 
happen for an OLPC kernel.  Certainly the amount of work is commensurate 
with the nature of the changes.  Having seen the RT patch set, that is 
invasive and would also require similar effort.
- Above has to be done daily, virtually in realtime.  The minute that 
kernel build breaks (which will be frequently), it will be disabled in 
the build makefiles.  If it remains disabled for extended periods of 
time then end users in the community get disgruntled.
- DaveJ is currently teetering on the edge of sanity, and doesn't need 
one more straw to break the camel's back.
- As was pointed out earlier, the path to the Fedora kernel leads from 
upstream.

In short, its generally hugely expensive in terms of ongoing manual 
labor/torture to keep another kernel afloat.  Not to mention that as 
Matt points out, any layered kernel modules (ie the dirty decoder/codec 
like stuff) won't work, or otherwise fragment the user base.




More information about the fedora-advisory-board mailing list