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
