https://fedorapeople.org/groups/389ds/ci/nightly/2020/10/16/report-389-ds-base-1.4.4.4-20201015gitb8b1691.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.
https://github.com/389ds/389-ds-base/pull/4375
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le
>
> Hi,
>
> For my part, I have seen mapping tree misconfiguration popping from time to
> time but it is quite rare (maybe 7 or 8 times in 15 years)
> So although in pure term or architecture your proposal is IMHO the cleanest,
> in term of risks it is not a good solution:
> there will lik
https://github.com/389ds/389-ds-base/pull/4382
--
389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
htt
Hi Pierre,
you expressed my concerns much clearer. I agree with you,
Thanks,
Ludwig
On 15.10.20 13:00, Pierre Rogier wrote:
Hi,
For my part, I have seen mapping tree misconfiguration popping from
time to time but it is quite rare (maybe 7 or 8 times in 15 years)
So although in pure term or
Hi,
For my part, I have seen mapping tree misconfiguration popping from time to
time but it is quite rare (maybe 7 or 8 times in 15 years)
So although in pure term or architecture your proposal is IMHO the
cleanest, in term of risks it is not a good solution:
there will likely be regressions (i
