On Tue, 2004-04-27 at 23:17, Josh Boyer wrote: > At _any_ point during the development of the kernel for a new product > release, do the kernel developers bring in changes from external trees? > If so, which ones? It's something that we've done in the past which we're trying very hard not to do for FC2. (and we're doing a good job at sticking to that so far). A number of reasons for this.. - The 'lets stay close to mainline' mantra. - 'lets not end up with a fork of random trees that only ever lives on in a Red Hat tree'. - External trees often contain stuff that never makes it into mainline for good reason. > Obviously during development they pull from the kernel.org tree. For > FC2, the kernel has gone from pre 2.6, to 2.6.5 already. It's pretty > common knowledge that Red Hat/Fedora kernels contain changes by the > kernel developers for various reasons (i.e. bug fixes, backports, etc). > So, do those changes contain fixes from other trees or all they all done > "in-house"? Stuff in the current kernel falls into a few categories.. - Red Hat specific hacks (A lot less of these though these days, I think the noninterative oldconfig thing is all thats left) - New features we developed which upstream either isn't ready for, or won't take for 2.6, but folks repeatedly ask for (Exec-shield, 4G/4G, etc.) - Stuff that's destined for mainline real-soon-now. A few cherry picked bits of -mm, and bits and pieces developed by Red Hat folks. - Infrastructure work needed for other bits in FC (SELinux patches etc) These also are destined for upstream, but may block on other stuff going in first etc.. > If they do pull in changes from external trees, it might be easier to > open bugs and point them to the tree for a fix. Or maybe I am just > blabbering. I guess I am just curious. Pulling individual fixes is deemed the safer alternative, but even better is to get this stuff into mainline. Pressure the external tree maintainers to get their stuff merged. If it's a critical bug it's certainly something we'll consider adding to the tree until it gets fixed in mainline. > Thanks for all the responses. They are appreciated even though I sound > like a broken record :) Here's some fun stats with the number of patches against the current kernel I have checked out.. My current FC2 working tree from last weekend - 27 patches Fedora Core 1 - 102 patches RHL9 - 143 patches RHEL3 - 315 patches. FC1 was off to a bad start with a pretty high patchcount from the beginning, and in a lot of cases, it's a real pain to maintain, so keeping this count as low as possible without sacrificing usability is a goal worthy of trying to maintain for as long as possible. Having a heavily patched tree isn't necessarily a bad thing (ie, RHEL) as long as you have enough folks dedicated to maintaining it. We have that bodycount for RHEL3, we don't for FC. Keeping things as close to upstream also means that a lot of bugs we hit are likely reproducable upstream, and can end up getting fixed up by the upstream maintainer, which takes additional burden off of us, giving us more time to concentrate on other things, like finding new interesting ways to break the NVIDIA driver. j/k 8-) By keeping patch count low, it also gives us extra incentive to push all the bits we come up with back upstream asap too. Dave
