On Tue, 2006-05-09 at 04:35 +0530, Rahul Sundaram wrote: > 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? > > > > Does the kernel still use pristine source + patches, or are we just > > using a random git tree? > > pristine source + patches. That's what's in CVS. I was talking with Jeremy about this on IRC this past weekend. There are git trees inside of RH that the kernel developers use, and patches are generated from that. Maybe not everyone uses them, but the git trees do exist. Getting a git tree (or trees) opened up might help. For projects like OLPC, it could help quite a bit. People see those changes as they happen and you can get feedback that much sooner. But for projects like Xen, I'm not too sure. That lives largely in it's own community and while RH is certainly a big player, getting those changes upstream is largely the responsibility of the Xensource folks. Publishing git trees is only one part though. That's the easy part. The hard part is when you want to take these kernels, package them into RPMs, and have them actually be used by mere mortals. That's what Greg is getting at. He wants to package the CCRMA kernel so it can be used by people via RPM. Or at least that's what I think he wants to do. josh