On Mon, Feb 22, 2016 at 06:33:47PM -0800, Quanah Gibson-Mount wrote:
I would like to see us retire slapd-bdb and slapd-hdb.
How much work is it costing to keep them around?
I agree completely with marking them deprecated and having configure
disable them by default, but I also don't see a lot of reason to
actually delete them as long as they keep working without having to
spend any effort.
Is there any intermediate level in between deprecated and deleted?
Demote to contrib?
For removing something like back-[bh]db or slapd.conf that was actually
the default in the past, and therefore probably still has many users who
have just carried working setups forward, I would personally be even
more conservative: announce the removal (not just the fact that it's
deprecated, but that it will be removed in a specific version e.g. 2.6),
mention it in as many places as possible (mailing list, admin guide, man
pages), and include that notice in a release a year or two in advance of
the actual removal.
Another possibility is back-perl.
back-shell? Its manpage advises building slapd without threading, but
last I looked, that doesn't even work any more. (Speaking of things that
are broken enough to be considered for deletion...)
But to me, these both also look like things that should be disabled by
default and marked deprecated, but not necessarily deleted outright, as
long as they aren't actually broken.
I'd like to see the passwd/sha2 overlay be considered for promotion.
Same. In fact I'd go as far to say I'd like to see it, or something like
pbkdf2 or bcrypt, become the default, but that's wishful thinking as
long as I lack cycles for helping make it happen.
I thought there was talk a while ago of autogroup possibly being
promoted, is that still a possibility?