[fab] Non-standard kernels in the Fedora Multiverse

[Josh Boyer]

On Wed, 2006-05-10 at 17:23 -0400, Bill Nottingham wrote:
> 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*?

I think it requires experimentation in small steps.  Start by using the
tools whatever upstream you're tracking uses.  In the case of the
kernel, use git.  You can generate patches for RPMs out of that.  Or if
you want to use pristine+patches, use StGit.  I don't think we'll be
able to sit here and ponder up grand solutions to this problem without
at least trying a few things here and there.

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

The biggest headaches come from big, intrusive patches.  Something small
like a new driver isn't too hard to keep in-sync with upstream simply
because the amount of change in upstream is fairly localized.

josh