Re: branching

[David Kastrup]

Mike Solomon <address@hidden> writes:

> On Dec 11, 2013, at 11:36 AM, David Kastrup <address@hidden> wrote:

[...]

> But that’s no good - we have to find a solution.  Modularity, while
> perhaps a good long term solution, is a long ways away.  How are we
> going to deal with this in 2014?

By making headway and not be defeatist about it?  "is a long ways away"
is terribly close to "somebody else's problem" and "let's think about
this the year after next year".

>> And I see no-one in the current developer base who would work in that
>> direction.
>
> One of my major projects - eliminating calls to translate_axis, was
> moving exactly towards this (https://codereview.appspot.com/7185044/).

It's called "Caches the interior skylines of vertical axis groups and
systems." and there is no obvious reason why cached skylines would not
be translatable.  Of course, there is the non-obvious reason that a
translation might lead to a violation of skyline invariants due to
numerical effects, but that's nothing that can't be caught in-place.

In other words: there are several different issues that are conflated
here in a single patch.  There is no inherent reason why not being able
to use translate_axis will lead to more modular code.  It seems actually
more likely that having to track offsets separately is going to make
stuff more complex.

"More modular" does _not_ mean "eliminate functions doing a common task
because of restructuring data in a manner incompatible with using a
common function on it".  Most graphic subsystems deal with this kind of
thing by including a "current transform matrix" in their data sets so
that transforms do not need to be performed until the final operation
(actually, since PostScript also has the concept of a current transform,
it's easy to pass this job to the backend).  Of course, many skyline
operators require a common coordinate system for the involved skylines,
so there are points where one needs to normalize.

> The less we’re calling translate_axis (the Defense Against the Dark
> Arts function of LilyPond) in the backend, the more we can isolate
> functionality to certain places and the less surprises there are.

I don't see the connection.

The net effect for the user, according to the Changes file, appears to
be that outside-staff-priority stops working unless special callbacks or
special commands (\tupletOutsideStaffPriority) are used, regardless of
whether the grobs have the side-position-interface or not.

As a result, it is not all that surprising that there were several grobs
overlooked.

Does this have anything to do with "caching the interior skylines of
vertical axis groups and systems"?  Not apparently.  Does it have
anything to do with "Removes the translate_axis call from
axis-group-interface outside-staff positioning"? Not obviously.  There
is no explanation in the review or patches for that.

I've taken a look at the current patch:
<URL:https://codereview.appspot.com/7185044/#msg53> rather suggests that
there is considerable work needed to get this into commit quality.

There is also no explanation of the great plan behind this anywhere, and
since this is a whole lot of stuff muddled in one review, it appears
unlikely that the work will be split into a sequence of commits that
give some overall direction (it would be quite untypical for you to
split the material in a review, however involved, into separate
commits).

You say that there is plenty of followup work.

> I’ve for the time being dropped it until we can work out these
> community problems.

The respective comments are in
<URL:http://code.google.com/p/lilypond/issues/detail?id=3134#c64> and
the following.  They have nothing whatsoever to do with "community
problems".  What they _have_ to do with is release timing.

Yes, the time frame I estimated for getting 2.18 was too optimistic.
However, if this code would have been pushed at that stage and/or I
would have been required to review it until it was of stable release
quality, the time for getting every kink ironed out would have been much
much larger.

You stated that the bug fixes of previous patches were mostly done by
Keith since you were removing yourself from development due to bad
communication of mine.  That does not really fit the time frames: your
respective announcement came after most of the fixes.

What figured in in your lack of time and/or concentration at that time,
as it very well should, is you getting married, and working a whole lot
with your ensemble to boot.

The actually sad thing about the whole thing is that your withdrawal
from active development (based on the feedback on a different issue)
gave 2.18 and me as its warden the breathing room that was required for
it to get into releasable state.

So while you paint it as a loss for LilyPond, the _direct_ consequence
of your withdrawal regarding those patches was a net win for getting the
release done.  The indirect consequences, namely you stopping also fixes
necessary for getting to a release and, as you claim, others turning
away from LilyPond, were obviously not positive.

-- 
David Kastrup