[fab] Non-standard kernels in the Fedora Multiverse

[Christopher Blizzard]

Tim Burke wrote:
> 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.

I've got Marcelo Tosatti and David Woodhouse to do this work for OLPC. 
I'm hoping that they will be able to do most of their work upstream and 
we pick up changes that way but I know that we're going to have local 
changes both for the same of experimentation and because maybe we need 
something that hasn't been taken.  In either case, we're going to have 
to have a variant for OLPC.  I'm sure that RHEL doesn't care about the 
things that we do and we don't care about 90% of the RHEL drivers. :)

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

Good advice.

> - DaveJ is currently teetering on the edge of sanity, and doesn't need 
> one more straw to break the camel's back.

So how do we make his job easier?  I know the gatekeeper job - I've done 
it in Mozilla-land and it sucks.  It's a total burnout job.

> - As was pointed out earlier, the path to the Fedora kernel leads from 
> upstream.

It is but the idea that "one kernel is enough" doesn't fly when you're 
supporting more than one product, certainly from the RHAT side of the 
fence and even more so when we're trying to enable other people to use 
Fedora to experiment and do other interesting things.  We need to get 
creative and find a way to scale instead of just saying "it's hard."

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

Yep, so let's think about how we can spread the load and try and get 
external people involved.

--Chris