asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
hyc(a)symas.com wrote in ITS#8240:
> Our patch response was too hasty. There is no OpenLDAP bug here, the real
> issue is production binaries being built with asserts enabled instead of
> compiling with -DNDEBUG. That's an issue for packagers and distros to resolve.
> Closing this ITS, not an OpenLDAP bug.
Maybe I missed something. But this is the first time I've heard about -DNDEBUG
being mandatory when compiling binary packages for production use. Does it
have other effects?
And what are general rules for assert statements in OpenLDAP code?
In my own (Python) code assert statements are supposed to be only triggered if
something goes wrong *internally* (type issues etc.). If somebody manages to
trigger an assert statement with invalid input from "outside" I always
consider this to be a serious bug revealing insufficient error handling even
though e.g. web2ldap just logs the exception but won't crash. YMMV, but please
clarify.
I also wonder whether there are more mandatory rules for building packages and
where I can find them.
Please don't get me wrong: My inquiry is in good faith to avoid unnecessary
ITS based on misunderstanding.
Ciao, Michael.
1 year, 6 months
New release policy for OpenLDAP
by Quanah Gibson-Mount
There's been ongoing discussion about making changes to the current release
strategy with OpenLDAP.
Traditionally we've (for the most part) kept new features out of the
release branch and did our best to primarily focus on bug fixes only. There
have clearly been exceptions when warranted (such as support for LMDB,
etc). However, this policy has had the effect of keeping significant
improvements from being made readily available to end users of the
software. To address this, we're looking at implementing the following:
Starting with OpenLDAP 2.5, the OpenLDAP project will use a new release
process.
Odd numbered releases will contain only bug fixes
Even numbered releases will allow for minor new features
This will allow for end users who want stability to focus on odd numbered
releases while allowing those who need/want newer features to be able to
make use of them.
Constructive responses to the new release strategy welcome.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
3 years, 4 months
Re: New release policy for OpenLDAP
by Hugh McMaster
On Wed, 29 Jan 2020 at 05:46, Quanah Gibson-Mount wrote:
> But my point was, I think it’s a fallacy to tie software quality and
> frequency of releases.
I encounter way too much software today that
> releases frequently, but what it releases is poorly (or not at all) QA'd,
> etc. And it's a nightmare to deal with. I'd rather they slowed down and
> got their software in better shape than constantly release, well, crap.
No-one was suggesting a two-week release cycle (e.g. Wine) or three major
releases a year (e.g. ICU). But there comes a point where simply releasing
bug fixes (although very important for stability) for many years at a time
delays the release of important other work.
That’s what Howard wants to address with this change.
Out of interest, what frequency of minor and patch release do believe is
appropriate for this project?
Hugh
3 years, 4 months
Re: New release policy for OpenLDAP
by Gavin Henry
> Odd numbered releases will contain only bug fixes
> Even numbered releases will allow for minor new features
>
> This will allow for end users who want stability to focus on odd numbered
> releases while allowing those who need/want newer features to be able to
> make use of them.
>
> Constructive responses to the new release strategy welcome.
>
Sounds good! Although odd numbers seems to feel like something risky, i.e.
a new feature, whereas even numbers feel nice and comfy, boring and just
bug fixes. Maybe just me!
Gavin.
--
Kind Regards,
Gavin Henry.
3 years, 4 months
OpenLDAP BoF session at FOSDEM?
by Michael Ströder
HI!
Is anyone of the OpenLDAP devs around at FOSDEM this year?
Would it make sense to apply for a BoF session room to discuss things
face-to-face?
Ciao, Michael.
3 years, 4 months
2.4 commit review
by Quanah Gibson-Mount
A few commits stacking up, so would like to review them for inclusion in an
eventual 2.4.49.
I think all of the following look good for RE24, but wanted to confirm
specifically on (a) the GnuTLS changes, (b) the cleaner error handling
during connection setup, and (c) the Totp changes.
OpenLDAP:
ITS#9067 fix syntax evaluation of preferredDeliveryMethod
ITS#8753 Set minimum GnuTLS version to 3.2.2
ITS#9071 Document "tls none" for back-ldap
ITS#9069 Do not call gnutls_global_set_mutex()
ITS#9077 slapo-unique Let the loop finish
ITS#9095 insert missing commit at end of slapindex processing
ITS#9091 drop attr mappings added in an aborted txn
ITS#9100 relax domainScope check for absent value
ITS#9112 cleaner error handling during connection setup
Contrib:
Totp: ITS#9055 Introduce a combined password scheme
TotP: ITS#9055 Accept previous token
LMDB:
ITS#9068 fix backslash escaping
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
3 years, 4 months
ldap0 does not work with RE24
by Michael Ströder
HI!
It seems I'm experiencing a regression when running tests of
python-ldap0 with current RE24 which does not fail with 2.4.48:
test016_cancel (__main__.Test00_LDAPObject) ... munmap_chunk(): invalid
pointer
ERROR
There was this change for ITS#9124. So I guess it's causing this regression.
Could someone look into this?
Ciao, Michael.
3 years, 4 months
