On 10/04/2012 06:07 PM, Quanah Gibson-Mount wrote:
--On Thursday, October 04, 2012 11:29 PM +0000
> 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.
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
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
Certainly, here's a recent example:
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
> 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.
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration