Re: [Lilypond-auto] Issue 3256 in lilypond: Patch: Eliminates side poisition calculations for system-start-text grobs.

[David Kastrup]

Apparently not posted on the issue itself, so replying to the list.

"address@hidden" <address@hidden> writes:

> On 30 mars 2013, at 08:27, address@hidden wrote:

>> commit 6e4e69f2735a764eab2e6f70f83546461da0203b
>> Author: Mike Solomon <address@hidden>
>> Date:   Fri Mar 29 05:55:13 2013 +0100
>> 
>>    Uses special X alignment for instrument names.
>> 
>> I propose reverting it since using the instrumentName for prefatory
>> material is documented and previously working behavior address@hidden d it 
>> is not
>> clear what this will break in addition to incipits.  So it is not
>> really fit to be included in a stable release at this point of time.
>
> It is not clear what this patch does and doesn't break until people
> use it.  Unfortunately, the regtest checker does not pick up on
> certain differences, so it is important for users testing the software
> to signal these.  I fix them right away.

You can't fix what has not been reported, and we are talking about
functionality that is used by users, based on recommendations in our
code base and snippets.

> You are absolutely right that it is not clear what this will break in
> addition to incipits, but I'd rather deal with that as it crops up

The time frame for it to crop up is not available if we are planning to
make a stable release.

> as it is impossible to know given our current regtest checking
> suite. With Phil's pixel comparator this sort of problem will go away,
> but that'd need to get integrated into the build system.
>
> Fixes are quick, so I just need to know the problem.  I can then fix
> it ASAP.

You can't fix the code from users.  We have had several followup issues
from this patch already which makes very clear that code in our own code
base relied on previous behavior.  It is far too optimistic to assume
that user-level code would not rely on previous behavior.  Fine-tuning
the balance between improvement and damage is a process taking months,
based on feedback from users as well as discoveries in our own code base
from developers.

The fallout we have seen so far makes _very_ clear that this patch is
unsuitable for inclusion in a stable release.  Mixing it with several
spontaneous followup issues will cause things to go uncontrollably
unstable.  Either this patch can be done well-confined _without_
numerous repercussions (and that does not mean rolling lots of loosely
related followup fixes elsewhere into the same patch, but an actually
well-confined patch with well-confined and expected changes), or it is
off the plate for a timely stable release.

The desire to push in patches like this was the reason I called off the
stable release in the first place.  It was you who said we should try
for it if it is feasible.

This patch obviously makes it unfeasible, and if you try wedging in a
flurry of followup patches to make up for it, there will be no stable
release.

It was fine to try and see whether a long-standing problem can be fixed
with a reasonable amount of effort and impact.  But when one sees that
the impact is quite larger than expected, one needs to adapt one's
plans.

You can't have both a stable release and patches pushed in at last
minute that are shown to have a large destabilizing impact.

It is not possible to have both, and I am tired of being fought as the
bad guy for having to point that out time and again.

-- 
David Kastrup