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