>>> Quanah Gibson-Mount <[email protected]> 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 > <[email protected]> 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>
