[Freeipa-devel] [PATCH] 0014 Add final debug message in installers

[Petr Viktorin]

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³