[fab] Non-standard kernels in the Fedora Multiverse

[Jeremy Katz]

On Mon, 2006-05-08 at 18:57 -0400, Christopher Blizzard wrote:
> We're going to need to do something similar for One Laptop at some 
> point, but I'm hoping that will just be a kernel variant, not an 
> entirely separate package.  But we'll need some weird stuff in any case. 
>   Compressing memory on the fly, odd memory management and VM stuff, etc.
> 
> This is going to be more and more of a problem, not less.  How do we get 
> bleeding edge features into the kernel without causing pain to our 
> kernel guys?  Can we get the kernel guys to just start using an external 
> git repo for everything to start?  (Are they already doing that now?) 
> Is there a way we can re-think our processes so that we can actually 
> make this easier for our kernel folks instead of making it harder?

Git repos don't magically fix things, though.  What happens when patches
fail to merge cleanly (common) or things just fail to build (more
common).  Just "use an external git repo" doesn't help the fundamental
problem which is that the upstream kernel moves very quickly across the
entire source tree.  Therefore, any set of changes which aren't
extremely isolated (eg, beyond a driver) is highly unlikely to Just Work
without a significant effort.  And I don't see any simple process
changes on our side making things magically better.

> Does the kernel still use pristine source + patches, or are we just 
> using a random git tree?

It's pristine source + patches, although there tends to be "latest Linus
-git snapshot" as a patch.  Trying to merge *more* trees than that makes
it just that much harder to a) manage and b) get upstream kernel
developers to care about any bugs.  Which, given the resources for
fixing Fedora kernel bugs, the latter is incredibly vital

Jeremy