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
