lilypond-devel
[Top][All Lists]
Advanced

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

Re: Resolving standoffs


From: David Kastrup
Subject: Re: Resolving standoffs
Date: Mon, 13 Apr 2020 17:33:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Kevin Barry <address@hidden> writes:

> Hi David,
>
> Although you have changed the subject to "Resolving standoffs" your
> email reads like an attempt to force a resolution - in your favour -
> of one *particular* standoff.

Yes and no.  It is foreseeable that with an influx of developers into
LilyPond, there will be future situations of comparable kind to resolve
and so it makes sense to figure out how we want to approach
resolution-finding in that case.

> It seems to be more of a protest than an attempt to elicit discussion.

A "protest" would imply that my role here is that of being powerless,
and that of Han-Wen is to be in power to stop contributions of mine.  So
the diagnosis of "protest" on its own already makes a statement about
the governing structure of LilyPond, and finding out what kind of
governing structure should determine how we work on LilyPond is part of
what I consider this a good occasion for getting feedback on.

> I am both a lurker and not capable of understanding the disagreement
> between you and Han Wen, so I can't offer an opinion on it. And
> obviously take my view with a grain of salt, but is it not typical for
> this development community that, when there is some kind of
> irreconcilable disagreement, that the proposal just dies?

For better or worse, we have not yet had the situation that
irreconcilable disagreement arose over a pure syntactical change that a
developer wanted or needed for the sake of moving in an experimental
direction.

That is: we have had a number of such changes every few years from
different people for various reasons, and none of them was ever blocked
by other developers without alternative proposal and without any
justification other than that the blocking party did not want the other
developer to work in a particular direction.

So the kind of irreconcilable disagreement we have here is new because
there is no alternative proposal or no negative consequence as a
counterweighing interest.  There basically is just an "I don't want it,
and I don't believe that it would be useful for the person proposing
it."

> I don't know if it's frequent or not, but I saw it happen with many
> discussions that arose after the recent in-person meet (they died in
> standoffs).  It seems to be the norm. Is it only a problem now that it
> is holding up something you are advocating?

It is a problem now where there is no alternative proposal for enabling
long-running work on alternative implementations and no negative impact
on the code.  It's the first time that we have someone blocking
refactoring with a view of future progress because he does not want to
believe another developer can make use of it, and not because of actual
tangible drawbacks.

This refactoring allows strictly more implementation methods than
previously.  As one terminal option, it is much easier to _revert_ with
a script (rather than dealing with merge conflicts from future
development when reverting in the version control system) than it is to
create it or maintain the conflicts in parallel development branches
differing in syntax.

Of course, resolving this in a different manner is also a possibility,
but the implemented solution here is what more or less came out as the
best-liked alternative with least impact on code readability serving
this purpose.  So a different resolution requires a different proposal,
and general agreement that this is also an acceptable way of writing
things.

-- 
David Kastrup



reply via email to

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