kernel updates from external trees

[Dave Jones]

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