On 10/04/2012 06:07 PM, Quanah Gibson-Mount wrote:

--On Thursday, October 04, 2012 11:29 PM +0000 richm@stanfordalumni.org wrote:

...

If a customer reports such a problem, Red Hat will respond.

Again, reactive rather than proactive.

Red Hat is not entirely reactive.

...

...

There have been approximately 450 committed fixes to RE24 since 2.4.23 was released. So you have about 5% of the fixes in your build. That is just so very encouraging to hear, isn't it? As a customer, wouldn't you truly feel that Red Hat was doing its best for you, but grabbing a full 5% of fixes to OpenLDAP? And lets not forget a fair number of those patches you have actually have zero to do with OpenLDAP itself, but with MozNSS... So we're down to what? 3%?

If you will concede the point that quantity != quality, then so will I.

Certainly, but a fair number of those commits are actual bug fixes. 2.4.23 in particular had some significant issues.

...

So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new features or regressions, ever?

We have introduced new features, sure. MDB and delta-syncrepl for MMR would be examples. But they don't impact existing functionality.

Famous last words.

And certainly can be the case that regressions are introduced. I'm not saying to immediately upgrade to the latest OpenLDAP release every time it comes out. One has to have some common sense about it. However, it has been over 2 years since 2.4.23 was released. Many significant and real issues have been fixed since that 2.4.23 was done, with numerous fixes in the syncrepl area and the cn=config DB, which Red Hat deploys on RHEL6.

Ok. Fair enough. This then gets to the point about whether the Red Hat OpenLDAP maintainers would be willing and able to do this.

...

If this is really the case, then why would Debian or any other distribution not want to rebase every time OpenLDAP has a 2.4.x+1 release? The FAQ says ". . . upgrading to newer versions is often desireable but also means introducing change into stable releases, which is exactly opposite to the point of release stability". So it's ok for Debian to take a hard line for release stability, but not Red Hat? Or is your problem really that Red Hat doesn't openly proclaim that the OpenLDAP server included with the distribution is not for "a large site, a complicated installation" or the like? So if Red Hat were to provide such a disclaimer, it would be ok for Red Hat to take a hard line for release stability?

Debian provides a backports channel that allows its users to update to later releases. And no, I don't find Debian's hard line any more acceptable, but at least they provide a supported solution. Red Hat doesn't provide any supported alternative.

Ok. This is feasible. I know that Red Hat has done things like this in the past. This is something that could be done.

...

So what's the difference between Debian and Red Hat with respect to OpenLDAP? That is, why bash Red Hat's handling of OpenLDAP and not Debian stable? I suppose the same thing applies to Red Hat - if a Red Hat customer has "a large site, a complicated installation, or problems for which [they] need to seek help here", they will probably be willing to pay extra for extra attention, in the form of adding additional resources to build and maintain OpenLDAP themselves, or hiring a firm like Symas.

If you think I don't bash Debian, then you haven't been paying attention. ;) In any case, my point is about improving how Red Hat handles things, not about bashing. There are improvements that can be made.

It's hard not to pay attention to you. But I guess your point is that Debian does provide a supported way to get newer versions of packages even on older, stable releases, and that is an important distinction.

...

Most of the complaints I see from users in the OpenLDAP community are about the TLS/SSL support in RHEL6. Do you have evidence to the contrary?

Certainly, here's a recent example: https://www.openldap.org/lists/openldap-technical/201210/msg00024.html

I guess I missed it, but exactly which OpenLDAP release(s) had the fix for this particular problem? That is, how could Red Hat have avoided this problem by rebasing to a later OpenLDAP?

...

...

...

...

And then that leads to the question of what exactly they are paying RedHat for support for in the first place.

I like how you use "RedHat" instead of "Red Hat".

I like how you avoided addressing my point.

I see your point. I get it - the OpenLDAP community is not happy with the way Red Hat handles OpenLDAP. If you are really, truly concerned about Red Hat customers using OpenLDAP software, what are you going to do about it? If your goal is to get Red Hat to rebase OpenLDAP releases on a regular basis, how can you achieve that goal? Complain to Jan and I in an OpenLDAP ITS? Bash Red Hat to every user who has the temerity to use rhel/fedora/centos and ask a question in #ldap and # openldap and the OpenLDAP mailing lists? If a critical mass of paying Red Hat customers tells Red Hat that they are not happy with OpenLDAP, then Red Hat will do something about it. That's the demand side.

Red Hat (and probably all OS distributions) has the same problem to some extent with all upstream projects. There are probably Apache upstream community members who are unhappy with the way Red Hat deals with Apache releases.

As for the supply side, if Jan and the other OpenLDAP maintainers feel that it is better to rebase than patch, then that's a good start. They are the ones who are on the hook - it's their necks if things don't work correctly. Once they convince themselves, then they have to convince QE, Doc, support, and management that it really is the best policy. And part of it is Red Hat's policy towards release stability, which adds additional process, but is workable.

I will note that Mandriva, at least, continually updates the version of OpenLDAP they ship, unlike most distributions, so it definitely isn't all. And my point is, Red Hat could do better, and I'd like to see them do better. I'd like to see Debian/Ubuntu do better too. I.e., this isn't specific to Red Hat, but the discussion here is about Red Hat, and what it can do. I discuss Debian and what it can do better with the Debian devs on their openldap dev list.

Then I'd like to hear what Jan and the other Red Hat OpenLDAP maintainers have to say.

--Quanah

--

Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.

---

Zimbra :: the leader in open source messaging and collaboration