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