lilypond-devel
[Top][All Lists]
Advanced

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

Re: line_count issues


From: David Kastrup
Subject: Re: line_count issues
Date: Tue, 18 Sep 2012 11:22:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Benkő Pál <address@hidden> writes:

> hi David,
>
> I saw you marked line_count related issues for backport.
> is that my task, yours or common?

Mine.

> what should or can I do?

I was actually planning to contact you in private about this.  I am in
the somewhat unfortunate situation of having admitted the line_count
changes into 2.16.0 where they cause changes including definite
regressions for some previous behavior, regressions that are not
continuing into 2.18.  The task I am faced with is to bring 2.16.1 into
a state where its behavior cures the regressions in 2.16.0 without
creating a divergence.

The goal is to be sure that people upgrading from 2.14.2 to 2.16.1 to
2.18.0 will not have to change some things for the first upgrade, and
change it back again for the second one.  So 2.16.1 should not veer off
the course only to get back.  For 2.16.0, I failed in that endeavor.

The patches I have marked "Backport" are those that I have to take into
consideration when deciding how to best fix that failure in 2.16.1.  I
won't take material into 2.16.1 that has not previously been released in
an unstable release and seen some exposure.  And I have to guess at the
likelihood that it will be reversed or partly reversed before 2.18.

The simplest course would be to reverse all the line_count material to
2.15.40 behavior.  However, there are definitely some things (like the
time signature stuff) where I am reasonably sure they'll stick around in
this form (because not much else makes sense as we figured out), so
moving forward from 2.16.0 rather than backward makes sense.

For other things, I just don't know yet.

> at the moment there's one line_count related issue I know and want to
> work on: multimeasure rests in nonstandard staves, see
> http://code.google.com/p/lilypond/issues/detail?id=2783#c36

Anything that has not been touched while getting to 2.16.0 will not get
backported unless it cures crashes or definite performance issues and
does not change the output of previously valid programs.

I am not happy about behavior-changing fixes to 2.16.0, but when they
are definitely putting out short-term regressions without creating
yet-another single-release behavior, I am taking a look at them.

That's what the "Backport" tag means.  Nothing more, nothing less.

-- 
David Kastrup



reply via email to

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