kernel updates from external trees

[Josh Boyer]

On Wed, 2004-04-28 at 08:49, Dave Jones wrote:
> 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..

Ah, now I am getting the answers I was looking for.  Once again, Dave to
the rescue :).

> 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..

Ok, I figured that was the case.

> 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.

Sometimes that is easier said than done, but you make a good point. 
Alot of the lag in merging an external tree is that it takes time, and
not many people have an excess of that :).

> 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-)

I suppose that the number of patches correlates with the number of
features the customer requires too.  And what those customers are
willing to pay to get support for those features.  Everyone knows the
saying "You get what you paid for" ;).

> 
> By keeping patch count low, it also gives us extra incentive to push
> all the bits we come up with back upstream asap too.

I like the direction the FC2 kernel is going.  Not only does it make
things simpler for the reasons you stated, but it allows lowly kernel
hackers like myself to see some of the focus points that Red Hat works
on.

I am looking forward to when the Fedora CVS tree opens up.  It'll be
easier to come up with patches when you can diff against the current
source, instead of an older RPM where you don't know if something has
been fixed already or not.  That's not to say that the kernel developers
are necessarily looking forward to getting more patches from us, but at
least we can try to help when needed :).

thx,
josh