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

Antw: Re: OpenLDAP 2.5 plans and community engagement



>>> Quanah Gibson-Mount <quanah@symas.com> schrieb am 09.08.2019 um 01:47 in
Nachricht <1AB0E954D8914B6FF6B9655F@[192.168.1.144]>:

> 
> ‑‑On Wednesday, August 7, 2019 8:08 AM ‑0400 David Magda 
> <dmagda@ee.ryerson.ca> wrote:
> 
> 
>>> People who write the list are already provided the information on these
>>> options.  What would the project having yet another build of the same
>>> things provide?
>>
>> Perhaps all of these people started providing these binaries because the
>> project itself didn't / doesn't? Maybe all of those other efforts
>> could be refocused to build binaries served from (say)
>> repos.openldap.org. The infrastructure seems to already be present:
>> perhaps it just needs to be centralized / concentrated?
> 
> The LTB project bundles some additional functionality of its own with its 
> builds, and is specificaly designed to be separate from the system level 
> installation.  It also does things like link against the OpenLDAP 
> recommended TLS libraries (OpenSSL).
> 
> For RHEL, RedHat has made it quite clear they have no interest in bundling 
> OpenLDAP nor maintaining it (it does compete with their 389DS and RHDS 
> products, after all).  They also made the mistake of writing their own code

> to link against MozNSS for the majority of RHEL7 against the advice of the 
> OpenLDAP project.  Another issue with the RHEL builds is they default to 
> using the deprecated back‑hdb backend, etc.
> 
> Debian/Ubuntu continue to link to GnuTLS for theoretical licensing reasons 
> with OpenSSL.  However with the OpenSSL license change with OpenSSL 3.0 
> this hopefully will no longer be the case.
> 
> I.e., 'providing' a build of OpenLDAP has a number of complexities.  If the

> OpenLDAP project were to do such a thing, should it only provides linked to

> OpenSSL?  If so, what version of OpenSSL? Should it have SASL capabilities 
> (linking to cyrus‑sasl)? Should it provide SASL/GSSAPI? If so, which 
> Kerberos library?  Should those builds provide experimental backends like 
> back‑sql or only fully supported backends?
> 
> Quite frankly, the project developers are spread thin on time as it is now.

> Taking on the burden of then trying to support X random user's needs or 
> complaints is not particularly enticing.  With the source, they can build 
> OpenLDAP exactly the way *they* need it to be built.
> 
>>>> So 2015 was quite product, but most of 2016‑2017... not so much.
>>>
>>> 2015 had a lot of serious bugs in its release, the releases were rushed,
>>> and the result of rushing was bad.  I don't think 2015 is a "good"
>>> example of how things should be done.
>>
>> That is an argument for timed releases.
> 
> I fail to see how that's the case.  What I see is that we need to:
> 
> a) Ensure we have CI/CD

I wonder: Doesn't CI provide "builds" as a by-product? What configuration
options are used for those builds? Couldn't that simpley produce an "OpenLDAP
nightly" (similar to Mozilla's Firefox)?

> 
> and
> 
> b) Better/expanded test cases & databases to validate against
> 
> and
> 
> c) more participation from the community in testing/validating new features

> and code fixes.
> 
> Just throwing out a new release every 6 months doesn't help with any of the

> above.
> 
> ‑‑Quanah
> 
> 
> ‑‑
> 
> Quanah Gibson‑Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>