>Your patch would have scratched your itch, but the burden to keep perl-ldap
>maintainable, understandable & compatible [even for that RFC violation of your >tool] would be on the maintainer(s). Understood. I'm not trying to trivialize the job of the maintainer (I've been there!), but this is a simpler situation than the one that many maintainers have (this being all Perl!). The patch is not horribly complex. I understand your reservation about option hell, but think in terms of grey, not black and white, how terrible of a problem are we really looking at? >What if another patch came in asking for another RFC violation that would >negatively impact your patch? Which one should then prevail? Since the non-standards-enabling is enabled by option, I'm having a hard time thinking of a case where this would be an issue: the choices are "allow controls without change record" or "don't allow controls without change record"; we've already covered both. Not saying it can't happen, help me find a case here! In lieu of a concrete example (help me here!): if the other interfering violation were mutually exclusive, one (of several possible) approaches would be to give them different enablement options, and make the enablement options mutually exclusive. Yes, this is the start of a slippery slope into option hell, but again, how often has this come up?. What would a conflicting option be? >Did you at least report the bug to IBM? >Because their non-standards compliant tool is the cause of the whole >discussion. I offered to as a part of quid quo pro.
