>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am
09.08.2019 um 01:47 in
‑‑On Wednesday, August 7, 2019 8:08 AM ‑0400 David Magda
>> 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)
. 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
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
OpenSSL? If so, what version of OpenSSL? Should it have SASL
(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
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)?
b) Better/expanded test cases & databases to validate against
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
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: