Hi William,
Things are not black and white:
there is a huge difference between a fix with limited impact (like
adding some check in configuration tools or in the server) and redesigning
something that is used in many different contexts for every request handled
by the server ...
In the first case we could easily mitigate the risk by testing and be
fairly confident, in the second case the tests are too complex to achieve
the same confidence and we should take this kind of risk only if there were
a serious benefit to balance it, but in this case, there are other
solutions with less risks.
I can understand it could seem too conservervative and frustrating but that
is the price when working on mature projects. If you do not do that, the
product becomes unstable, and users quickly abandon it.
Regards,
Pierre
On Mon, Oct 19, 2020 at 1:27 AM William Brown <wbrown(a)suse.de> wrote:
> 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
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...
--
--
389 Directory Server Development Team