Hi,
So some of the arguments here is that we are introducing risk for
something that is not really a big problem. Or, simply not worth
investing in. From a Red Hat perspective "we" would _never_ fix this,
it's just not a problem that comes up enough to justify the work and
time. But... The initial work has been done by the upstream community
(William). So from a RH perspective we are getting this work for free.
Personally I don't see this code change as "very" risky, but this is a
very sensitive area of the code. That being said, I am not opposed to
adding it, but... I think we need much more testing around it to build
confidence in the patch. I would want tests that deal with suffixes of
varying size, names, nested levels/complexity:
o=my_server.com
dc=example,dc=com
dc=abcdef,dc=abc (same length as suffix above - since the patch
uses sizing as a way of sorting)
dc=test,dc=this,dc=patch
I want tests that are adding and removing subsuffixes, and
sub-subsuffixes, and making sure ldap ops work, and replication, etc. I
want tests that use many different suffixes at the same time and many
subsuffixes - some customers have 50 subsuffixes. Our current CI test
suite does not have these kinds of tests, and we need them.
As of today I'm not comfortable with the current CI tests to ack this
patch, but if we can ramp it up and cover more scenarios it would be a
step in the right direction. This is all just my humble opinion, we are
all still just talking :-)
Mark
On 10/19/20 6:47 AM, Pierre Rogier wrote:
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
<mailto:wbrown@suse.de>> wrote:
> On 16 Oct 2020, at 17:48, Pierre Rogier <progier(a)redhat.com
<mailto:progier@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
<mailto:389-devel@lists.fedoraproject.org>
To unsubscribe send an email to
389-devel-leave(a)lists.fedoraproject.org
<mailto:389-devel-leave@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
_______________________________________________
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