[Date Prev][Date Next]
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
On 10/04/2012 06:07 PM, Quanah Gibson-Mount wrote:
> --On Thursday, October 04, 2012 11:29 PM +0000
> email@example.com 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
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.
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> Zimbra :: the leader in open source messaging and collaboration