On 04/18/2012 12:38 AM, Dmitri Pal wrote:
On 04/17/2012 01:13 PM, Petr Viktorin wrote:
On 04/17/2012 06:46 PM, John Dennis wrote:
Thank you for the explanation Petr, it's very much appreciated.

I do have a problem with this patch and I'm inclined to NAK it, but I'm
open to discussion. Here's my thoughts, if I've made mistakes in my
reasoning please point them out.

The fundamental problem is many of our command line utilities do not do
logging correctly.

Fixing the logging is not terribly difficult but it raises concerns over
invasive changes at the last minute.

To address the problem we're going to introduce what can only be called
a "hack" to compensate for the original deficiency. The hack is a bit
obscure and convoluted (and I'm not sure entirely robust). It introduces
enough complexity it's not obvious or easy to see what is going on. Code
that obscures should be treated with skepticism and be justified by
important needs. I'm also afraid what should really be a short term
work-around will get ensconced in the code and never cleaned up, it will
be duplicated, and used as an example of how things are supposed to
work.

So my question is, "Is the output of the command line utilities so
broken that it justifies introducing this?" and "Is this any less
invasive than simply fixing the messages in the utilities cleanly and
not introducing a hack?"



Yes, it's a hack, because it needs to be non-invasive. It does that by
not modifying the scripts themselves, but just wrapping them in the
context handler. So no functionality is broken, there are just
problems with extra messages printed or not printed. I think that's
the least invasive thing to do. So the answer to your second question
is yes. I'm not experienced enough to answer the first one.

I opened https://fedorahosted.org/freeipa/ticket/2652 to track the
larger issue that needs solving: removing the code duplication in
these tools. This includes a common way to configure logging and
report errors.



Let us do the hack and pick the cleanup task in 3.0 so that we have
things done correctly for future.
If this task is not enough let us open other tasks to make sure that we
track correctly the need to the right fix.
We can even revert the change in 3.0 and go a different path.



NACK

We have agreed outside this list to drop the issue for 2.2, and fix it properly for 3.0.

--
PetrĀ³

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to