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

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