[fab] Non-standard kernels in the Fedora Multiverse

[Christopher Blizzard]

Bill Nottingham wrote:
> 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*?

As an example, OLPC is both of these things.  In the end it's probably a 
separate config, but between now and when we ship we're going to need to 
do patches + stock kernel for testing and integration.  This is really a 
product lifecycle issue for me and right now our current process are 
really only around one lifecycle: the Fedora and RHEL lifecycle.

THe question that I see is: how do we allow people to experiment in some 
kind of blessed way that enables them to do so, and still allows our own 
processes to move forward and scale?

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

Not sure.  We're probably shy about writing tools, but I think we need a 
stronger problem definition and research before we even start talking 
about ideas around tools.  I feel like we're getting some sense of the 
problem statement, though.

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

It's most certainly a stick!  :)

I think that "keep your own maintainer" isn't enough.  I wonder how we 
can move to "act as a co-maintainer."  i.e. let's give Dave Jones a 
break and still enable us to scale this out a bit.

--Chris