On 16 Oct 2020, at 17:48, Pierre Rogier <progier(a)redhat.com>
wrote:
Hi William,
I agree with your architecture points and that is why I said my proposal is a less
appealing trade off.
My real concern is your last point:
we just do not know and IMHO we are unable to predict what (or if) config will cause
problems, and I am afraid we will only discover it when people start to complain.
So I still think that the benefit/risk ratio is bad)
I think this wasn't my point. The thing is *any* change will have that
"unknown" risk. Our job is to qualify and identify as many of those risks as we
can, to remove them as unknowns. Think about the work recently to merge the changelog to
the main db, or BDB to LMDB work, even changing from perl to python for installation.
These are all significantly larger changes, which would be "much riskier" but
all of them have been managed effectively by the team communicating, coordinating,
analysing, designing and testing changes.
So I really don't accept this "unknown" risk argument. I have laid out a
design that explores the configuration, how it works today and how the values are
currently trusted, and a process to manage and understand this change in a way to minimise
the risk. There are associated tests, and it passes with address sanitiser, and other test
cases for mapping trees, replication and others.
If we just say "unknown risk" at every change we make we'd never progress.
We may as well packup and go home, the project is completed.
So I still stand by my design and the PR I have submitted in this case, and if there are
concerns about esoteric configurations, then we should identify and understand them too
beyond the testing I have already provided.
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia