Fedora Core 4 Test 1 slips

Fedora Core 4 Test 1 slips

Posted Feb 24, 2005 7:53 UTC (Thu) by davej (subscriber, #354)
In reply to: Fedora Core 4 Test 1 slips by jd
Parent article: Fedora Core 4 Test 1 slips

> The biggest is that they don't support enough hardware.

Oh please, if it compiles, and isn't a steaming turd, chances are its enabled in Fedora kernels.

> They already patch the kernel, so it's not as if they would be doing
> anything arcane.

We're not patching it /that/ much. Asides from a handful of features like exec-shield, Xen and a handful of other bits there's really not that much in there these days. FC4 is currently around 50 or so patches off the top of my head, and I'm working to get this even lower by the time FC4 ships. FC3 is somewhat higher, because its based on 2.6.10, and has a bunch of fixes from 2.6.11rc added to it. (After a rebase to 2.6.11, it'll drop off to around 40-50 or so again).

> Adding madwifi and other unofficial & not included drivers would go a
> long way to making Fedora an instant hit with newbies to Linux

And what happens when upstream then implements something completely different, and I put out an update kernel ? Users get screwed by the change. Merging drivers & subsystems into vendor trees is *not* the way to go. The only drivers added to the Fedora kernel over the last year or so have been speedtouch, and the ipw wireless drivers. Speedtouch was merged so that it could be used out of the box on FC3 (as it was getting merged upstream at the same time, but hadnt yet appeared in a released kernel).
ipw is a little more borderline. It needs work, but at some stage should actually be something mergable.

This stuff needs to be upstream. Read the Fedora manifesto. It clearly states that we strive to be as close to upstream as possible in the kernel we ship. Having a vendor tree filled with random versions of various drivers pulled from here there and everywhere is the road to madness.

I've seen this happen firsthand - We merge a driver, a bug is found, we scratch our heads, ask the upstream developer to take a look - "not interested as its a red hat kernel and there are other patches there".

That model is doomed. The only way this can work is by getting as much as
humanly possible into Linus' tree so everyone is working from as common a base tree as possible.

---

to post comments