--On Friday, October 06, 2017 10:16 PM +0100 Howard Chu hyc@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