[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Don't hardcode a limited set of markup signatures. (issue969046)

From: David Kastrup
Subject: Re: Don't hardcode a limited set of markup signatures. (issue969046)
Date: Wed, 19 May 2010 11:42:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Mon, May 3, 2010 at 4:22 AM, David Kastrup <address@hidden> wrote:
>>>>> For one reason or another, whenever I review code from you it degrades
>>>>> into a fight. I am not quite sure why this always happens.
>>>> Because you don't bother taking the contributions of other people
>>>> seriously.  You don't read the code comments, even after you asked for
>>> Thanks for explaining this; it's obviously my fault.   I'll go back to
>>> where I came from.
>> Nice touch, but it's not your work going in the bin.
> Just for the record: I am ok with the current form of the patch.

As you can see by now, that does not change a thing.  As long as the
patch is not in the comfort zone (and that concerns more the patch area
than its quality by now) of others with commit privileges, nobody is
going to take the responsibility.  The corresponding bug report (for a
pending patch) has been marked unimportant, the patch set is effectively
being dropped.

I admit that I have been unfair to you interpreting your comments as an
act of hypocrisy, applying vastly different standards for vetoing
others' contributions than to your own work.

It was, for all that I know, intended as friendly advice, and I reacted
not according to your likely intent, but rather its expected outcome.
You'd likely give yourself the same advice.

But whether or not you are just giving out advice, it does not have the
net effect of a veto on your own code or that of other committers.  For
an outsider, intentional or not, it does act as a veto.

And the net result remains that having one's work cast away for
non-technical reasons is not exactly encouraging further contributions.
Should the arbiter be communication or code quality?  Admitted, both are
not entirely independent: feedback contributes to code quality and
design, and comments and code streamlined for maintainability are a form
of communication as well.

For the sake of maintainability, my overreaction to your comments
(namely obliterating anything for which you suggested changes I could
not bring myself to agree with) should actually have made a change to
the better.

There are possible further improvements: the terminal and non-terminal
symbols of the grammar could be moved to be closer to the corresponding
music function nomenclature.

But at the current point I see no point in wasting further resources on
polishing code that is going nowhere.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]