"Trevor Daniels" <t.dani...@treda.co.uk> writes:
> Carl, Although I'm not a current developer, I'd like to comment.
>
> In general I agree, but with the caveats below:
>
> Carl Sorensen wrote Tuesday, January 17, 2012 1:27 AM
>
>
>> So after hearing from most of the currently-active developers, I think a
>> reasonable goal for 2.16 would be:
>>
>> 1) Work through the outstanding issues involved in issue 2070 -- Don't
>> wrap EventChord around all note heads. This is probably a big issue, but
>> I think with David working on it it will happen quickly once we work
>> through the issues. To me, this is the biggest outstanding issue, but I
>> think it will be worth tackling.
>
> This looks like a big undertaking. I think we need to be advised
> by David about this. Well worth doing if he is agreeable and
> confident.
It depends on the progress we are able to make here. This changes the
internal representation of music expressions (usually taking less space
than before and better matching the expectations for a given input).
That means that programs working on music expressions will get to see
different input. It is not a change to make in a stable release series.
It forms an excellent complement to the work I have been doing on the
parser groundwork, and paves the path for continuing with it. But it is
slated as a change of internal representation, and if it does not get
into 2.16.1, the next opportunity is 2.17. I would be loath to miss
this opportunity to tie the groundwork I have been working on into a
more consistent whole than it can currently be done, but if this does
not make it at least into early release candidates, it does not belong
in 2.16.
>> 5) Remove translations if they are not updated to 2.16. The 2.14/2.15
>> manuals can be used if desired. Having non-updated manuals removed may
>> serve as an incentive to get them all translated.
>
> I'd prefer to see all translations carried forward, even though they
> are incomplete, much as we carry forward the English documentation,
> even though much of it is incomplete.
We have "translation of committish" in the start of translated files.
Maybe we could use this information for automatically generating
(localized) messages "warning: this section may be outdated. It
corresponds to the English version from xxxx-xx-xx. The English version
has last been changed on xxxx-xx-xx.". Possibly with hyperlinks.
>> B) Guile 2.0. I think there's enough going on with Guile 2.0 on
>> their side (adding local-eval back in) that we shouldn't push this
>> for the next stable release.
>
> Leave out. This looks as if it needs a long run in.
Our current code does not depend on local-eval. The code would be
cleaner, faster and more compact if it did, but not breathtakingly so.
The "local-eval" implementation that is likely going to end in 2.0.4 is
not independent from the other Guile code, so we don't have the option
of just taking it as a fallback for versions 2.0-2.0.3. I don't
particularly like our current code, but I don't see that it makes sense
to make Ian's life even harder by requiring local-eval at the current
point of time (meaning 2.16). Even though I am not happy about the
message this sends to upstream Guile who currently invest a lot of
thought and effort into bringing local-eval back.
If we reach a decision of "2.16 will be Guilev1 only" at some point of
time, I might be tempted to change the embedded LilyPond code back into
using local-eval in the release branch once 2.16 has been branched off
from master. It would be, well, more stable and have less overhead for
#{ ... #}. But master itself should not do Guilev1-only changes
deliberately.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
