[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites

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

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

Again, reactive rather than proactive.

>> 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.  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.

> 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.

> 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.

> 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: 

>>>> 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.



Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra ::  the leader in open source messaging and collaboration