Re: OpenLDAP 2.5 plans and community engagement

[David Magda <dmagda@ee.ryerson.ca>]

On Jul 24, 2019, at 14:01, Ondřej Kuzník <ondra@mistotebe.net> wrote:
> 
[…]
> In general, moving to Gitlab should let us integrate CI much better, especially
> if there are people willing to integrate and manage external runners. As
> mentioned above, we could definitely do with more regular testing on non-Linux
> platforms, e.g. *BSD or Windows+MSYS2. Pull requests might then also be
> automatically tested.

FreeBSD has a team dedicated to building third-party packages (“Ports”):

	https://www.freebsd.org/portmgr/index.html
	https://www.freshports.org/net/openldap24-server/

You may wish to contact them, and/or the OpenLDAP port maintainer, about ways to set up build environments and what they do already:

	https://www.freebsd.org/doc/handbook/ports-poudriere.html

> Let us know what the pain points have been with OpenLDAP when you were just
> starting, right now and if you have a suggestion how to make it easier to start
> using it. Or if you wanted to contribute, has anything discouraged you?
> There are things we might not be able to influence easily (LDAP itself can be
> complex), but a fresh look might help direct efforts in the right direction.

You mention binary packages on the website:

	http://www.openldap.org/faq/data/cache/108.html

And yet when people come to this list, the response is often “that’s an old version, you need to upgrade”, especially for Red Hat.

While things like MariaDB/PostgreSQL packages are in various distros, those projects provide repos that people can use with yum/apt to get the latest versions. Providing ‘official’ first-party packages, at least for RHEL/CentOS and perhaps Ubuntu (LTS), would go a long way towards allowing people to have all the newest bug fixes.

Having predictable, time-based releases would also help admins and distributions keep up to date. Past releases:

	OpenLDAP 2.4.48 (2019/07/24)
	OpenLDAP 2.4.47 (2018/12/19)  -7 months
	OpenLDAP 2.4.46 (2018/03/22)  -9 months
	OpenLDAP 2.4.45 (2017/06/01)  -9 months
	OpenLDAP 2.4.44 (2016/02/05)  -16 months
	OpenLDAP 2.4.43 (2015/11/30)  -3 months
	OpenLDAP 2.4.42 (2015/08/14)  -3 months
	OpenLDAP 2.4.41 (2015/06/21)  -2 months

So 2015 was quite product, but most of 2016-2017... not so much.

I mentioned this last year:

	https://www.openldap.org/lists/openldap-technical/201807/threads.html#00005

I have no idea what the the best schedule (annual, biannual, other) would be, but anything would be an improvement over sleep(rand()).