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