Meeks: Linux on the (consumer) Desktop

* Fri Jul 07 2006 <name> <email>
- Unified rhel and fedora srpm

> Actually, no. They begin with the mainline kernel and start applying patches on top of it. Some of these patches, of course, were in Fedora.

This is just playing semantic games. All the patches that Red Hat do on recent mainline kernels end up in Fedora, which are then (attempted to be) pushed upstream. So, by the time this RHEL kernel is based on some x.y.z upstream release, many of those Fedora patches won't even apply (because they are already part of mainline). Of course, features that RH decide not to support in RHEL (that would be the streamlining thing I was talking about) will not appear, will not be patched and will not be compiled.

> But by the time they start a new development cycle, Fedora is already several kernel versions in the future.

I do not see why that would be surprising at all. And, of course, this is where the "trunk" of new RHEL is being forged: by applying Fedora specific patches, testing them in the wild, getting feedback and pushing them upstream. This is how they _leverage_ the community. If they did not do that, that would be really stupid. And I think Red Hat's balance sheet speaks volumes about them not being stupid.

PS. If you are trying to suggest that RHEL kernel is physically not a branch of some SCM Fedora system, then you may even be correct. But, that is not what I was talking about when describing the non-secretive trunk of the Red Hat's distro development.