--On Friday, October 06, 2017 10:16 PM +0100 Howard Chu <h...@symas.com>
wrote:
its7442 - Add debug statements when index_intlen values are out of
range <https://github.com/quanah/openldap-scratch/tree/its7442>
Looks pointless.
Well, the man page is not clear on this point. I'm fine dropping the
debug statements, but what about the manpage updates which clarify the
min/max allowed values?
Then we should also document all the other places where for example our
integers accept a max value of 4294967295 or 18446744073709551615 too?
It's stupid. Nobody is using 256 byte integers. Nobody is using integers
bigger than 256 bytes. (Come on, 2^2048? really?) It's a limit that no
one will ever hit in practice.
Well, I can certainly see why someone might expect they could set the
minimum lower than 4 (even if that would be less than optimal). ;) I.e.,
you're focussed on maxsize, but the report covers both min & max. Any
reason not to document that the default value of 4 is also the minimum
allowed? I'm fine with dropping the patch as well.
its8511 - Fix documentation for multimaster, deprecate mirrormode
<https://github.com/quanah/openldap-scratch/tree/its8511>
Gratuitous change, existing docs and practices are already established.
Hard enough to get people to update their docs, this is a bad idea.
This change is not gratuitous in the least. The misinformation in our
current documentation leads to constant confusion among end users, who
often do not want to go to the lengths necessary to deploy the
*concept* that is mirror mode, and instead just want to do
"multimaster", so they leave our current misnamed 'mirrormode'
parameter set to false. Fixing the documentation to match the reality
of what's being configured is a positive step to removing confusion and
to stop misleading end users on what is being done. I've provided
numerous links from the mailing list where this caused problems for end
users before. Our parameters should reflect what they actually do.
You're talking about confusion for new users, meanwhile you're just
creating confusion for existing users. Existing users tend to complain
more because they have more invested into their running deployments. This
is a bad idea.
Since it deprecates the existing parameter, it has no effect on current
deployments. If anyone ends up confused due to the fact that the
documentation was clarified to reflect objective reality, I'll be more than
happy to help them. We already have endless complaints that our
documentation is overly confusing. This fix helps address that problem.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
