JP Vossen on 6 Mar 2011 13:13:24 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Exactly what is RedHat doing?

On 03/06/2011 06:24 AM, Rich Freeman wrote:
On Sat, Mar 5, 2011 at 7:42 PM, JP Vossen<>  wrote:

If this sticks it's sure not going to help, but IMO it's only making a bad
situation worse.

RHEL contributes all patches upstream, right?

 From what I've heard (which might not be true), RH has quite a few
full-time engineers focused on stuff like the kernel and other key
linux packages.  When problems arise they tend to be on the front line
with fixing them.  They contribute their patches upstream, which means
everybody gets to benefit for free from a bunch of really good
salaried linux devs.  It is also nice for really good kernel hackers
to have someplace to work.

Now, if you're an RHEL customer then you directly benefit from these
guys staying on top of the code that you're running, and you have
access to them as a support resource (though likely indirectly).  If
you're not one of their customers you still benefit, but likely a
little later in time and with fewer guarantees and nobody to yell at
if something gets missed.

Overall, I don't really see what they're doing as "bad for linux" -
they're contributing labor but ensuring that there is somewhat of a
premium value to paying them for it.  Most decent distros stay on top
of security bugs/etc, so many don't need this premium.  I think RH is
just trying to avoid making it so easy for other distros that their
customers have no real reason to stick with them.

I should have thought about my phrasing more carefully. When I said "bad situation" my head was in the weeds of kernel (re-)packaging, and understanding just what kernel you are using and how it is configured. I was also thinking of some of the RHEL-specific bugs/regressions that have popped up from time to time.

What I was *not* thinking about is the bigger picture you point out, so thanks for bringing it up.

On Sun, 06 Mar 2011 13:20:23 -0500 Sean M. Collins wrote:

> CentOS-Devs are in a bit of denial, as of late.

Interesting article. I was not aware of that security update patch issue or the part about packages being different. (Well, that's not totally true. I am aware that CentOS != RHEL, but as I've argued before it's usually close enough.)

I think backporting a security fix from 5.6 to 5.5 would be a terrible idea that completely destroys the idea of scheduled point releases. And as much as I'd like to see CentOS-6 released, I'd prioritize 5.6 first.

My knee-jerk thoughts are:
	a) Get CentOS-5.6 out ASAP
	b) Then get CentOS-6 out ASAP, while:
	c) Documenting the problems, needs, fixmes, etc.
	d) Write up RFHs (Requests For Help) for the community

CentOS says they need help, but others say they are hard to hard with or join (I don't know). Fine, meet in the middle. Core folks document stuff that's needed as little projects, them let the community come up with solutions or at least prototypes. I'm assuming here that 1) it's possible to create a useful RFH and 2) it's easier to modify "something" (provided by someone else) than it is to start from nothing. Either or both of those may be false in some cases, but I bet they are both true for lots of others. Some help has to be better than none, right? Track RFHs in the wiki maybe?

I've never tried this at home, and I am *sure* I am oversimplifying here, so can anyone point out where or how? It seems simple enough:
	1) extract the RHEL SRPMS into a build environment
	2) Remove/replace RHEL copyrighted material
	3) Build new RPMS

Certainly #2 is a huge task, but I'd think once it was done once and automated, it would not be all that hard to do the "diffs" in a point release. So I can see 6 taking a while, but I'm stuck for why 5.6 is a problem. And if it's not automated, well, I'd call that a self-inflicted wound (maybe a "fixme" from above?). I can also see the need to come up with new replacements from time to time, but CentOS branding exists, so it's not starting from scratch.

#3 is also a huge task, especially since there is so much mysticism surrounding the RHEL build farm. But again that work has been done already, else CentOS-5.5 (etc.) would not exist.

So what am I missing?

JP Vossen, CISSP            |:::======|
My Account, My Opinions     |=========|
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --