[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP 2.5 plans and community engagement
--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>