[fab] Non-standard kernels in the Fedora Multiverse

[Bill Nottingham]

Christopher Blizzard (blizzard at redhat.com) said: 
> I need to worry about the fact that I need a kernel that has wildly 
> different preferences and possibly patches than the stock fedora kernel. 
>  We will not be using the stock i686/i586 kernel.  We know we do most 
> of that work upstream, but what about the stuff that doesn't?  And the 
> fact that it has a different config?

A separate config on top of common upstream code is relatively simple;
it may break building, but it is generally easy to fix.

Keeping separate codebases working on top of upstream *cough*Xen*cough*
is another matter entirely. The question is how to make this easier
for people - tinderboxing? Alerts of breakage on new checkins *to upstream*?

What sort of tools can we make that make this easier, whether it's for
the Xen maintainers, the CCRMA people looking at real-time patches,
or even for someone who just wants to add a new-not-yet-upstream wireless
driver?  

> This is the one that I think we're going to have the most problems with. 
>  Even in the "play" case above, people still want reasonable security 
> updates.  And the farther that you fork from the main kernel the harder 
> it is to come back and apply security updates.
> 
> I'm not sure what to do about this case, but we need some creative 
> thinking.  We want people to be able to follow, modify and keep updates. 
>  From our tree (think productize, as OLPC does) our outside of our tree 
> (think audio projects/realtime patches.)  How do we enable that and 
> create the best incentives to keep updated as closely as possible?

The 'as currently done' approach would be:
- keep your own maintainer. Charge him with fixing it for each security
  update

This is not the most scalable solution, obviously. Perhaps this is
the carrot/stick that encourages people to get their code upstream;
I'm not sure.

Bill