Re: 2.16.1
Il giorno sab, 10/11/2012 alle 14.35 +0100, Francisco Vila ha scritto: 2012/11/9 Phil Holmes em...@philholmes.net: I've just built 2.16.1 and will be uploading it later this evening. All seems OK except I tried to create a regtest comparison versus 2.16.0 and instead got a comparison of 2.17.6 versus 2.16.0. Grenouille is sending daily reports of failed builds. The message is not informative enough. Do you know what's happening? I looked at the log each time and did not understand what happened for several days, until I realized just now that one of the meanings of the signal 24 that killed LilyPond is XCPU (CPU time limit exceeded), so I raised CPU time limit a bit (from 10 minutes to 15). Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org; David Kastrup d...@gnu.org Sent: Friday, November 09, 2012 6:32 PM Subject: Re: 2.16.1 On Fri, Nov 09, 2012 at 06:02:04PM -, Phil Holmes wrote: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Friday, November 09, 2012 5:36 PM Subject: Re: 2.16.1 I've just built 2.16.1 and will be uploading it later this evening. All seems OK except I tried to create a regtest comparison versus 2.16.0 and instead got a comparison of 2.17.6 versus 2.16.0. But you are certain that the binary itself is 2.16.1? How would it produce a comparison of 2.17.6? The binary is certainly named as 2.16.1 so I've no doubt that it is 2.16.1 - it was also built from stable/2.16 and there's not 2.17.6 code there. I'm assuming that VERSION has 2.17.6 unstable, and it does a regtest comparison with the highest numbered release - or at least says it does. I don't think this is likely to be more than an oddity. Regtests are built from the just-compiled binaries to any regtest tarballs you have in regtests/ . You evidently had a regtest/lilypond-2.16.0-test.tar.gz and -2.17.6-test- tarballs in that directory. Each tarball contains various .eps and/or signature files which are used to produce the comparisons. See the code for more details because about what's in the regtest tarballs and how they're used, because I'm not clear on it. - Graham From my experience, that's not exactly what happens. As you say, the build creates a comparison of regtests built against the current binary with any tarball in the regtests/ directory. For me, this was only 2.16.0 - I was careful to ensure this. We would then expect this output to be put in a 2.16.1 directory and labelled 2.16.1. What happened in practice was that the output was put in a 2.17.6 directory. This then killed the upload later on in the evening, since it could not find the 2.16.1 directory. I renamed it and restarted the upload, which appeared to finish correctly. I'm now going to update VERSION and hope the website updates during the day. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
2012/11/9 Phil Holmes em...@philholmes.net: I've just built 2.16.1 and will be uploading it later this evening. All seems OK except I tried to create a regtest comparison versus 2.16.0 and instead got a comparison of 2.17.6 versus 2.16.0. Grenouille is sending daily reports of failed builds. The message is not informative enough. Do you know what's happening? -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
- Original Message - From: Francisco Vila paconet@gmail.com To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Saturday, November 10, 2012 1:35 PM Subject: Re: 2.16.1 2012/11/9 Phil Holmes em...@philholmes.net: I've just built 2.16.1 and will be uploading it later this evening. All seems OK except I tried to create a regtest comparison versus 2.16.0 and instead got a comparison of 2.17.6 versus 2.16.0. Grenouille is sending daily reports of failed builds. The message is not informative enough. Do you know what's happening? -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com It looks like it's a problem with Grenouille. I ran patchy this morning to merge staging and had no problem. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
Phil Holmes em...@philholmes.net writes: I've just built 2.16.1 and will be uploading it later this evening. All seems OK except I tried to create a regtest comparison versus 2.16.0 and instead got a comparison of 2.17.6 versus 2.16.0. But you are certain that the binary itself is 2.16.1? How would it produce a comparison of 2.17.6? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Friday, November 09, 2012 5:36 PM Subject: Re: 2.16.1 Phil Holmes em...@philholmes.net writes: I've just built 2.16.1 and will be uploading it later this evening. All seems OK except I tried to create a regtest comparison versus 2.16.0 and instead got a comparison of 2.17.6 versus 2.16.0. But you are certain that the binary itself is 2.16.1? How would it produce a comparison of 2.17.6? -- David Kastrup The binary is certainly named as 2.16.1 so I've no doubt that it is 2.16.1 - it was also built from stable/2.16 and there's not 2.17.6 code there. I'm assuming that VERSION has 2.17.6 unstable, and it does a regtest comparison with the highest numbered release - or at least says it does. I don't think this is likely to be more than an oddity. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
On Fri, Nov 09, 2012 at 06:02:04PM -, Phil Holmes wrote: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Friday, November 09, 2012 5:36 PM Subject: Re: 2.16.1 I've just built 2.16.1 and will be uploading it later this evening. All seems OK except I tried to create a regtest comparison versus 2.16.0 and instead got a comparison of 2.17.6 versus 2.16.0. But you are certain that the binary itself is 2.16.1? How would it produce a comparison of 2.17.6? The binary is certainly named as 2.16.1 so I've no doubt that it is 2.16.1 - it was also built from stable/2.16 and there's not 2.17.6 code there. I'm assuming that VERSION has 2.17.6 unstable, and it does a regtest comparison with the highest numbered release - or at least says it does. I don't think this is likely to be more than an oddity. Regtests are built from the just-compiled binaries to any regtest tarballs you have in regtests/ . You evidently had a regtest/lilypond-2.16.0-test.tar.gz and -2.17.6-test- tarballs in that directory. Each tarball contains various .eps and/or signature files which are used to produce the comparisons. See the code for more details because about what's in the regtest tarballs and how they're used, because I'm not clear on it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Releases 2.17.6 and 2.16.1
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org; David Kastrup d...@gnu.org Sent: Saturday, November 03, 2012 9:57 PM Subject: Re: Releases 2.17.6 and 2.16.1 On Sat, Nov 03, 2012 at 04:29:53PM -, Phil Holmes wrote: I finished building 2.17.6 about 30 minutes ago. Gub failed again, but I know how to fix this manually and have done so, so it's ready for upload. I suggest a moratorium on releases until GUB works. Too many things can go wrong when manual steps are required. TBH, I don't think I've ever had a completely problem-free GUB build, except when running the very long build from scratch. As it stands, I do understand what's going wrong and the manual steps to correct that and am pretty clear that this is down to the signature problem. A simple way to prevent it is to delete the signature directory, but I'd prefer to try to fix it. I've just pushed a commit to gperciva/gub that will likely fix this - although this is somewhat by inspection so if anyone knows more of the internals of gub and can comment, I'd be happy. This looks questionable to me: -NATIVE_BUILD_COMMITTISH=$(shell cat $(LILYPOND_REPO_BRANCH_DIR)/refs/heads/$(LILYPOND_DIRRED_BRANCH)) +NATIVE_BUILD_COMMITTISH=$(shell cat $(LILYPOND_REPO_DIR)/git/refs/heads/$(LILYPOND_DIRRED_BRANCH)) Isn't _BRANCH_DIR vs. _DIR how we distinguish between master and release/unstable and stable/2.16 ? Running lilypond make with the print target now prints out quite a lot of these variables. It gives: LILYPOND_DIRRED_BRANCH git.sv.gnu.org/lilypond.git/release/unstable LILYPOND_FLATTENED_BRANCH git.sv.gnu.org--lilypond.git-release-unstable BUILD_PACKAGE git://git.sv.gnu.org/lilypond.git?branch=release/unstable DOC_PACKAGE git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable TEST_PACKAGE git://git.sv.gnu.org/lilypond-test.git?branch=release/unstable NATIVE_BUILD_COMMITTISH bcda814afef1e8e11a376fbac6d5367ffa78fcbd LILYPOND_REPO_BRANCH_DIR downloads/lilypond/git.sv.gnu.org/lilypond.git/release/ LILYPOND_REPO_DIR downloads/lilypond On my GUB system, there is no directory anything like downloads/lilypond/git.sv.gnu.org, so I'm unclear what LILYPOND_REPO_BRANCH_DIR is intended to point to. As you see, LILYPOND_DIRRED_BRANCH points to foo/release/unstable, and I believe it is this that is used to distinguish the various buld targets. On further inspection, I wonder whether it's an error of logic. From lilypond.make, we have: LILYPOND_REPO_BRANCH_DIR=$(LILYPOND_REPO_DIR)/$(dir $(LILYPOND_DIRRED_BRANCH)) and the original command for the committish was: NATIVE_BUILD_COMMITTISH=$(shell cat $(LILYPOND_REPO_BRANCH_DIR)/refs/heads/$(LILYPOND_DIRRED_BRANCH)) so LILYPOND_DIRRED_BRANCH was effectively added to the path twice. Can't see it would ever have worked - think you must have been deleting the signature files? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Releases 2.17.6 and 2.16.1
Hi,
I have just been merging translation into stable (after checking
compilation, tests, and documentation). I am not totally happy with
2.16.1: we still have non-convergence on the line-count stuff (which I
will leave in its current state), and it is conceivable that there is
some regression concerning #{ \include ... #}. In particular with
regard to the latter, I am tempted to either cherry-pick some stuff that
has seen no serious exposure (issue 2939
http://code.google.com/p/lilypond/issues/detail?id=2939 is still in
countdown), or alternatively revert some performance-related patches of
mine that have been picked post-2.16.0. I'll have to do some testing to
figure out the exact scope of the problem and then make a decision.
On front of the unstable release, we are having several reviews in
countdown with 2.17.6 syntax, and I think we should roll out 2.17.6 as
soon as possible to avoid things getting too complicated on the
convert-ly front.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Releases 2.17.6 and 2.16.1
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Saturday, November 03, 2012 4:07 PM
Subject: Releases 2.17.6 and 2.16.1
Hi,
I have just been merging translation into stable (after checking
compilation, tests, and documentation). I am not totally happy with
2.16.1: we still have non-convergence on the line-count stuff (which I
will leave in its current state), and it is conceivable that there is
some regression concerning #{ \include ... #}. In particular with
regard to the latter, I am tempted to either cherry-pick some stuff that
has seen no serious exposure (issue 2939
http://code.google.com/p/lilypond/issues/detail?id=2939 is still in
countdown), or alternatively revert some performance-related patches of
mine that have been picked post-2.16.0. I'll have to do some testing to
figure out the exact scope of the problem and then make a decision.
On front of the unstable release, we are having several reviews in
countdown with 2.17.6 syntax, and I think we should roll out 2.17.6 as
soon as possible to avoid things getting too complicated on the
convert-ly front.
--
David Kastrup
I finished building 2.17.6 about 30 minutes ago. Gub failed again, but I
know how to fix this manually and have done so, so it's ready for upload. I
will do the upload when we're not using my internet connection for anything
else... (This evening or tonight). So 2.17.6 should be visible during
tomorrow.
For anyone interested in why Gub was failing, it seems it's to do with using
a commitish as a signature of showing whether make test, etc., should be
re-run. Unfortunately the function that checked the cached signature was
looking in the wrong place. I've just pushed a commit to gperciva/gub that
will likely fix this - although this is somewhat by inspection so if
anyone knows more of the internals of gub and can comment, I'd be happy.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Releases 2.17.6 and 2.16.1
On Sat, Nov 03, 2012 at 04:29:53PM -, Phil Holmes wrote: I finished building 2.17.6 about 30 minutes ago. Gub failed again, but I know how to fix this manually and have done so, so it's ready for upload. I suggest a moratorium on releases until GUB works. Too many things can go wrong when manual steps are required. I've just pushed a commit to gperciva/gub that will likely fix this - although this is somewhat by inspection so if anyone knows more of the internals of gub and can comment, I'd be happy. This looks questionable to me: -NATIVE_BUILD_COMMITTISH=$(shell cat $(LILYPOND_REPO_BRANCH_DIR)/refs/heads/$(LILYPOND_DIRRED_BRANCH)) +NATIVE_BUILD_COMMITTISH=$(shell cat $(LILYPOND_REPO_DIR)/git/refs/heads/$(LILYPOND_DIRRED_BRANCH)) Isn't _BRANCH_DIR vs. _DIR how we distinguish between master and release/unstable and stable/2.16 ? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Documentation/changes.tely: refer people to bug tracker for changes in 2.16.1
---
Documentation/changes.tely | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index 83db4ea..b59ee7e 100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -35,11 +35,28 @@ See user manual, \NAME\
@finalout
-@node Top
-@top New features in 2.16 since 2.14
+@node Top, Fixes and changes after 2.16.0, (dir), (dir)
+@top New features in 2.16
+
+@menu
+* Fixes and changes after 2.16.0::
+* New features in 2.16 since 2.14::
+@end menu
+
@allowcodebreaks false
+@node Fixes and changes after 2.16.0, New features in 2.16 since 2.14, Top, Top
+@section Fixes and changes after 2.16.0
+@table @b
+@item 2.16.1
+Please refer to the bug tracker for
+@uref{http://code.google.com/p/lilypond/issues/list?can=1q=Fixed_2_16_1,
+issues fixed in 2.16.1}.
+@end table
+
+@node New features in 2.16 since 2.14, , Fixes and changes after 2.16.0, Top
+@section New features in 2.16 since 2.14
@itemize
@ignore
--
1.7.10.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Saturday, October 20, 2012 10:17 PM Subject: Re: 2.16.1 Phil Holmes em...@philholmes.net writes: David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? I've asked on the translator list whether they want to get something translated from all the cherry-picking, and feedback is incomplete yet. -- David Kastrup How are we looking now? There are a lot of changes in 16.1 compared with 16.0 - should it be released as a Release Candidate, do you think? (NB - I'm not sure how this would be done at present, just musing). -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
Phil Holmes em...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Saturday, October 20, 2012 10:17 PM Subject: Re: 2.16.1 Phil Holmes em...@philholmes.net writes: David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? I've asked on the translator list whether they want to get something translated from all the cherry-picking, and feedback is incomplete yet. -- David Kastrup How are we looking now? git log --oneline --summary origin/stable/2.16..origin/translation c78a460 Doc-es: update Changes. Documentation/es/changes.tely |9 + 1 file changed, 5 insertions(+), 4 deletions(-) d8f3f53 Doc-es: update Rhythms. Documentation/es/notation/rhythms.itely | 74 +-- 1 file changed, 60 insertions(+), 14 deletions(-) 09f338e Doc-es: fix another xref. Documentation/es/notation/input.itely |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) f199e87 Web-it: update for 2.16.1 release Documentation/it/learning/fundamental.itely |4 +- Documentation/it/learning/tweaks.itely | 16 Documentation/it/notation/pitches.itely |6 +-- Documentation/it/search-box.ihtml |2 +- Documentation/it/usage/lilypond-book.itely |2 +- Documentation/it/web/download.itexi |4 +- Documentation/it/web/introduction.itexi | 55 ++- 7 files changed, 61 insertions(+), 28 deletions(-) a072162 Doc-es: update Input. Documentation/es/notation/input.itely | 704 ++--- 1 file changed, 471 insertions(+), 233 deletions(-) c4248fd Doc-es: fix xref. Documentation/es/notation/text.itely |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) f5c01cc Doc-es: update Tweaks, Expressive, Keyboards and Spacing. Documentation/es/learning/common-notation.itely |9 ++-- Documentation/es/learning/tweaks.itely | 32 +++--- Documentation/es/notation/expressive.itely | 54 --- Documentation/es/notation/input.itely | 22 - Documentation/es/notation/keyboards.itely |7 ++- Documentation/es/notation/spacing.itely | 29 +++- 6 files changed, 103 insertions(+), 50 deletions(-) 7df3f88 Doc-es: partial update. Documentation/es/essay/engraving.itely|2 +- Documentation/es/learning/fundamental.itely |4 ++-- Documentation/es/notation/ancient.itely |2 +- Documentation/es/notation/changing-defaults.itely |2 +- Documentation/es/notation/fretted-strings.itely |2 +- Documentation/es/notation/percussion.itely|2 +- Documentation/es/notation/pitches.itely |6 +++--- Documentation/es/notation/simultaneous.itely | 12 ++-- Documentation/es/notation/vocal.itely |2 +- Documentation/es/search-box.ihtml |2 +- Documentation/es/usage/lilypond-book.itely|2 +- Documentation/es/web/download.itexi |4 +--- 12 files changed, 20 insertions(+), 22 deletions(-) 2784264 Merge remote-tracking branch 'origin/stable/2.16' into translation 94e770a Web-fr: update searchbox Documentation/fr/search-box.ihtml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 5198521 Doc-de: update commitsh strings to reflect status as up-to-date Documentation/de/essay/engraving.itely |2 +- Documentation/de/essay/literature.itely|2 +- .../de/extending/programming-interface.itely |2 +- Documentation/de/extending/scheme-tutorial.itely |2 +- Documentation/de/learning/common-notation.itely|2 +- Documentation/de/learning/fundamental.itely|2 +- Documentation/de/learning/preface.itely|2 +- Documentation/de/learning/templates.itely |2 +- Documentation/de/learning/tutorial.itely |2 +- Documentation/de/learning/tweaks.itely |2 +- Documentation/de/notation/ancient.itely|2 +- Documentation/de/notation/changing-defaults.itely |2 +- Documentation/de/notation/cheatsheet.itely |2 +- Documentation/de/notation/chords.itely |2 +- Documentation/de/notation/contemporary.itely |2 +- Documentation/de/notation/editorial.itely |2 +- Documentation/de/notation/expressive.itely |2 +- Documentation/de/notation/fretted-strings.itely|2 +- Documentation/de/notation/input.itely |2 +- Documentation/de/notation/keyboards.itely |2 +- .../de/notation/notation-appendices.itely |2 +- Documentation/de/notation/notation.itely |2 +- Documentation/de/notation/percussion.itely |2 +- Documentation/de/notation/pitches.itely
Re: 2.16.1
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Wednesday, October 24, 2012 4:28 PM Subject: Re: 2.16.1 Phil Holmes em...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Saturday, October 20, 2012 10:17 PM Subject: Re: 2.16.1 Phil Holmes em...@philholmes.net writes: David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? I've asked on the translator list whether they want to get something translated from all the cherry-picking, and feedback is incomplete yet. -- David Kastrup How are we looking now? git log --oneline --summary origin/stable/2.16..origin/translation When do you want 2.16.1 built? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Wednesday, October 24, 2012 4:28 PM Subject: Re: 2.16.1 Phil Holmes em...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Saturday, October 20, 2012 10:17 PM Subject: Re: 2.16.1 Phil Holmes em...@philholmes.net writes: David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? I've asked on the translator list whether they want to get something translated from all the cherry-picking, and feedback is incomplete yet. -- David Kastrup How are we looking now? git log --oneline --summary origin/stable/2.16..origin/translation When do you want 2.16.1 built? Don't panic. I still have no idea for the changes.tely file. Anybody with experience for that? Just point to Fixed_2_16_1 tags in the tracker? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
Le 24/10/2012 17:28, David Kastrup disait : Phil Holmes em...@philholmes.net writes: - Original Message - From: David Kastrup To: Phil Holmes Cc: Devel Sent: Saturday, October 20, 2012 10:17 PM Subject: Re: 2.16.1 Phil Holmes writes: David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? I've asked on the translator list whether they want to get something translated from all the cherry-picking, and feedback is incomplete yet. -- David Kastrup How are we looking now? git log --oneline --summary origin/stable/2.16..origin/translation [...] I apologize for the long read. I just wanted to point out just _how_ busy our translator team is, and usually their work is practically invisible to normal development. I just pushed a first part of updates for French. I still have to treat input.itely (titles headers), rhythms.itely and spacing.itely (because of xrefs), and hope to send them before Sunday. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PossibleSpam] Re: [PossibleSpam] Re: 2.16.1
2012/10/23 David Kastrup d...@gnu.org: Well, LilyPond could see a problem in connection with issue 2883. Not because of a Spanish version of changes.tely but because of outdated syntax in the Spanish version, syntax that just was not present in the English version, and that did not get converted with convert-ly. Well, the Spanish version in translation branch matches the English version in translation branch. Any changes in the original are usually announced by our 'make check-translation' script. While I was in translation branch, no change was made to the original, and therefore no changes were announced. This all comes from the lack of a translation branch for master/staging forked at the moment stable was forked. If translators are stuck with stable-translation, master/staging gets rapidly outdated. I have pushed to staging without the safety net. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PossibleSpam] Re: [PossibleSpam] Re: 2.16.1
Francisco Vila francisco.v...@hispalinux.es writes: 2012/10/23 David Kastrup d...@gnu.org: Well, LilyPond could see a problem in connection with issue 2883. Not because of a Spanish version of changes.tely but because of outdated syntax in the Spanish version, syntax that just was not present in the English version, and that did not get converted with convert-ly. Well, the Spanish version in translation branch matches the English version in translation branch. Any changes in the original are usually announced by our 'make check-translation' script. While I was in translation branch, no change was made to the original, and therefore no changes were announced. This all comes from the lack of a translation branch for master/staging forked at the moment stable was forked. If translators are stuck with stable-translation, master/staging gets rapidly outdated. I have pushed to staging without the safety net. Uhm, the above was not an accusation, just an explanation of the circumstances that made it desirable from a technical standpoint to get some elements of translation into staging already. It was clear that there would be a point of time when we would want to switch over, and it is just that work on issue 2883 rang the bell and said please start now. In a way, that is nice since it saves us from having to make an arbitrary decision of when to switch. That you are the only translator hit with changes.tely because you are the only one who ever worked on a translation of it does not mean that you are to blame for anything. I would have fixed this myself, but my mastery of Spanish is non-existent. I would not have been sure to leave the file in a correct state with regard to its contents. Issue 2883 will require a lot of heavy lifting from our developers and documenters, and it will also imply changes for users, even though with a large amount of backward compatibility. It was planned as a much more confined change, but it would not have made sense to not actually use the new possibilities for simplifying things elsewhere. Again, thanks for your part on the translation side for getting this change moved into a position where we can tackle it. It has passed the review pretty soon, but up to now has failed on the documentation build, simply because of our decision to not have translators work on two versions at once. That decision was quite reasonable, and now it is becoming reasonable to switch, and I am glad that the translation team is being remarkably responsive to problems that are in no way their fault but that can be addressed by them. Thanks! -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
2012/10/21 David Kastrup d...@gnu.org: David Kastrup d...@gnu.org writes: I'll merge stable/2.16 into translation. That should be unproblematic. The only reaction to that was a mail from Francisco which did not much to address this part of my plan. I did this right now, and afterwards discovered that there is a branch translation-staging. It is obvious that I suffer from a case of having not kept track of how translations are actually organized, so it may be possible that someone would need to hand-advance translation-staging to match translation, assuming that the organization of translation/translation-staging is similar to master/staging with regard to automatic testing. Ugh. Sorry for that. With the apparent lack of replies/comments/interest (possibly due to the translation list just downing any contribution from non-list-members), I felt I needed to move ahead in _some_ manner. Ok, it would appear that translation had been ahead translation-staging already before my merge, so it seems I should take no guesses here and just let people who actually know what translation-staging is for deal with it. I think translation-staging is an just experiment from John which he did not publicly announce. Or I don't remember it. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
Francisco Vila paconet@gmail.com writes: 2012/10/21 David Kastrup d...@gnu.org: David Kastrup d...@gnu.org writes: I'll merge stable/2.16 into translation. That should be unproblematic. The only reaction to that was a mail from Francisco which did not much to address this part of my plan. I did this right now, and afterwards discovered that there is a branch translation-staging. It is obvious that I suffer from a case of having not kept track of how translations are actually organized, so it may be possible that someone would need to hand-advance translation-staging to match translation, assuming that the organization of translation/translation-staging is similar to master/staging with regard to automatic testing. Ugh. Sorry for that. With the apparent lack of replies/comments/interest (possibly due to the translation list just downing any contribution from non-list-members), I felt I needed to move ahead in _some_ manner. Ok, it would appear that translation had been ahead translation-staging already before my merge, so it seems I should take no guesses here and just let people who actually know what translation-staging is for deal with it. I think translation-staging is an just experiment from John which he did not publicly announce. Or I don't remember it. In that case, if this experiment is no longer active, can we just remove this branch in order to avoid confusion? John? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
David Kastrup d...@gnu.org writes:
If it is ok with people, I'd propose the following course in order to
get the ball rolling again:
I'll merge stable/2.16 into translation. That should be unproblematic.
Then I'll merge translation into staging. This will require a bit of
cleanup and conflict resolution.
Ok, I got the merge here done. The only changes outside of
Documentation/xx strictly are now in
# modified:
Documentation/snippets/how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-2.ly
# modified: po/eo.po
# modified: po/es.po
# modified: po/it.po
The first has \consists something instead of \consists something and
is definitely correct. The history shows the following, making it
likely that this change might get backed out again by automatisms:
* commit 4ed5d7710416aff0a9e68f0d751b4e15c30fdf92
| Author: Phil Holmes m...@philholmes.net
| Date: Sun Sep 30 11:02:50 2012 +0100
|
| MakeLSR run with LSR tarball
|
| diff --git a/Documentation/snippets/how-to-print-two-rehearsal-marks-above-an
| index 80a56e2..8abdbaa 100644
| --- a/Documentation/snippets/how-to-print-two-rehearsal-marks-above-and-below
| +++ b/Documentation/snippets/how-to-print-two-rehearsal-marks-above-and-below
| @@ -30,7 +30,7 @@ independently of the other.
| \new Staff {
|
| \new Voice \with {
| - \consists Mark_engraver
| + \consists Mark_engraver
|\consists Staff_collecting_engraver
| }
| { c4 d e f
| @@ -38,7 +38,7 @@ independently of the other.
|c4 d e f
| }
| \new Voice \with {
| - \consists Mark_engraver
| + \consists Mark_engraver
|\consists Staff_collecting_engraver
|\override RehearsalMark #'direction = #DOWN
| }
|
* commit 0a12e59b93bceea2c94c61e5c35b17cd88fb6d8f
| Author: David Kastrup d...@gnu.org
| Date: Mon Aug 20 10:06:44 2012 +0200
|
| Issue 2760: CG wants all engravers to have double-quotes around them
|
| diff --git a/Documentation/snippets/how-to-print-two-rehearsal-marks-above-an
| index 8abdbaa..80a56e2 100644
| --- a/Documentation/snippets/how-to-print-two-rehearsal-marks-above-and-below
| +++ b/Documentation/snippets/how-to-print-two-rehearsal-marks-above-and-below
| @@ -30,7 +30,7 @@ independently of the other.
| \new Staff {
|
| \new Voice \with {
| - \consists Mark_engraver
| + \consists Mark_engraver
|\consists Staff_collecting_engraver
| }
| { c4 d e f
| @@ -38,7 +38,7 @@ independently of the other.
|c4 d e f
| }
| \new Voice \with {
| - \consists Mark_engraver
| + \consists Mark_engraver
|\consists Staff_collecting_engraver
|\override RehearsalMark #'direction = #DOWN
| }
|
With regard to the po files: they look like they match the current code
base better. However, I believe they are supposed to be generated
through some automatic process or whatever, so I am queasy about
updating them through a merge.
Suggestions how to deal with them? Merge or not?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: If it is ok with people, I'd propose the following course in order to get the ball rolling again: I'll merge stable/2.16 into translation. That should be unproblematic. Then I'll merge translation into staging. This will require a bit of cleanup and conflict resolution. Ok, I got the merge here done. The only changes outside of Documentation/xx strictly are now in # modified: Documentation/snippets/how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-2.ly # modified: po/eo.po # modified: po/es.po # modified: po/it.po The first has \consists something instead of \consists something and is definitely correct. The history shows the following, making it likely that this change might get backed out again by automatisms. I'll back this one out of the merge since there is no point in reinstating it, then letting it get overwritten again. This needs to be done through Documentation/snippets/new to stay. So that leaves the po files. Should I merge them over from translation or not? Francisco, any idea? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: David Kastrup d...@gnu.org writes: If it is ok with people, I'd propose the following course in order to get the ball rolling again: I'll merge stable/2.16 into translation. That should be unproblematic. Then I'll merge translation into staging. This will require a bit of cleanup and conflict resolution. Ok, I got the merge here done. The only changes outside of Documentation/xx strictly are now in # modified: Documentation/snippets/how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-2.ly # modified: po/eo.po # modified: po/es.po # modified: po/it.po The first has \consists something instead of \consists something and is definitely correct. The history shows the following, making it likely that this change might get backed out again by automatisms. I'll back this one out of the merge since there is no point in reinstating it, then letting it get overwritten again. This needs to be done through Documentation/snippets/new to stay. So that leaves the po files. Should I merge them over from translation or not? Francisco, any idea? Turns out that running make po-update on the current version I arrived at leaves stuff unchanged. That looks like a good sign with regard to its consistency, so I'll do the first merge to staging. That does not imply that translation now is severed from stable (or that we should merge translation back into staging): it just means that we got the first merge resolution done, incorporating the current translation work into staging. This does not affect translation at all: translation work of the stable branch should continue until complete. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
2012/10/22 David Kastrup d...@gnu.org: So that leaves the po files. Should I merge them over from translation or not? Francisco, any idea? Turns out that running make po-update on the current version I arrived at leaves stuff unchanged. Then do nothing. (Can you 'do nothing'?) I am not sure we are using Documentation/po files; we were in the past (and for a very useful purpose), but something is currently broken until somebody (me) takes it a look. root/po files are a different thing: they are for the program itself, not translations. This does not affect translation at all: translation work of the stable branch should continue until complete. Great! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
Here is another problem with translations that is rather curious:
commit bf1900d44f4937fe8e69e0e04e188a0c3daf5172
Author: Francisco Vila francisco.v...@hispalinux.es
Date: Thu May 31 11:18:26 2012 +0200
has some bit of English content in here that is totally out of place:
+@code{\tweak} now takes an optional layout object specification. It can
+be used for tweaking layout objects that are only indirectly caused by
+the tweaked event, like accidentals, stems, and flags:
+
+@lilypond[verbatim,quote,ragged-right,relative=2]
+\tweak Accidental #'color #red cis4
+ \tweak Accidental #'color #green es
+ g
+@end lilypond
and that causes documentation compilation of issue 2883 to fail after
syntax changes.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
2012/10/22 David Kastrup d...@gnu.org:
Here is another problem with translations that is rather curious:
commit bf1900d44f4937fe8e69e0e04e188a0c3daf5172
Author: Francisco Vila francisco.v...@hispalinux.es
Date: Thu May 31 11:18:26 2012 +0200
has some bit of English content in here that is totally out of place:
I first copy, then translate. If the number of translated paragraphs
is less than the number of copied paragraphs, that happens.
+@code{\tweak} now takes an optional layout object specification. It can
+be used for tweaking layout objects that are only indirectly caused by
+the tweaked event, like accidentals, stems, and flags:
+
+@lilypond[verbatim,quote,ragged-right,relative=2]
+\tweak Accidental #'color #red cis4
+ \tweak Accidental #'color #green es
+ g
+@end lilypond
and that causes documentation compilation of issue 2883 to fail after
syntax changes.
I have pushed the missing translation.
But the @lilypond snippet matches the one from original English in
Documentation/changes.tely , all snippets do match, so how can the
Spanish version break anything?
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PossibleSpam] Re: 2.16.1
2012/10/23 David Kastrup d...@gnu.org: Francisco Vila francisco.v...@hispalinux.es writes: 2012/10/22 David Kastrup d...@gnu.org: Here is another problem with translations that is rather curious: commit bf1900d44f4937fe8e69e0e04e188a0c3daf5172 Author: Francisco Vila francisco.v...@hispalinux.es Date: Thu May 31 11:18:26 2012 +0200 has some bit of English content in here that is totally out of place: and that causes documentation compilation of issue 2883 to fail after syntax changes. I have pushed the missing translation. But the @lilypond snippet matches the one from original English in Documentation/changes.tely , all snippets do match, so how can the Spanish version break anything? Well, the problem more or less is that changes.tely (in English or in Spanish) does not have a \version header. I don't really know whether this is intentional. It is possible that it is, in order to be able to show before/after pairs of LilyPond syntax without having the before version clobbered by convert-ly. In any case, incompatible syntax versions can not live simultaneously in the same file, it would be non-compilable. This is obvious. OTOH @example blocks with no music image are not compiled, but would they be affected by convert-ly? The problem now is not actually that Documentation/es/changes.tely contained unconverted material. The problem rather is that Documentation/es is the _only_ translation containing a changes.tely file at all! I can not see the problem. If you take a look at URL:http://lilypond.org/doc/v2.16/Documentation/changes/index.html, you'll see that the _only_ other language offered at the bottom of the page is español. git ls-files | grep changes.tely Now the changes have not been reset to empty in master yet as translations are generally still in 2.16 state. Now they are, pushed to staging. I have no idea why Spanish is the only translation caring about Changes. But while that is the case, it would be helpful if you already committed a change to staging resetting the Spanish Changes section to the state in the international Changes document. Once we change the translation branch over to master rather than stable/2.16, this change will get merged into translation with the initial master-translation merge. Is there any problem in translation branch yet? changes.tely in there is intended to be compiled during 'make doc' with the very same lilypond version that is compiled from that same branch during 'make'. Oh dear, this could be written much better, but I have now only 5 hours for sleeping, so I'm done for today. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PossibleSpam] Re: 2.16.1
Francisco Vila francisco.v...@hispalinux.es writes:
2012/10/23 David Kastrup d...@gnu.org:
Well, the problem more or less is that changes.tely (in English or in
Spanish) does not have a \version header. I don't really know whether
this is intentional. It is possible that it is, in order to be able to
show before/after pairs of LilyPond syntax without having the before
version clobbered by convert-ly.
In any case, incompatible syntax versions can not live simultaneously
in the same file, it would be non-compilable. This is obvious. OTOH
@example blocks with no music image are not compiled, but would they
be affected by convert-ly?
convert-ly does not know where LilyPond code starts or stops. Stuff in
@example will only escape conversion if some @{ @} or @@ inside confuses
a particular convert rule. For that reason, @verbatim may be preferable
in documentation sometimes.
The problem now is not actually that Documentation/es/changes.tely
contained unconverted material. The problem rather is that
Documentation/es is the _only_ translation containing a changes.tely
file at all!
I can not see the problem.
Well, LilyPond could see a problem in connection with issue 2883. Not
because of a Spanish version of changes.tely but because of outdated
syntax in the Spanish version, syntax that just was not present in the
English version, and that did not get converted with convert-ly.
I would lean towards giving changes.tely a version header so that
convert-ly gives it a lookover as well. I think that less likely to
cause problems than not giving it one. It would likely have avoided the
problem I have seen.
Now the changes have not been reset to empty in master yet as
translations are generally still in 2.16 state.
Now they are, pushed to staging.
Thanks.
Is there any problem in translation branch yet? changes.tely in there
is intended to be compiled during 'make doc' with the very same
lilypond version that is compiled from that same branch during 'make'.
Oh dear, this could be written much better, but I have now only 5
hours for sleeping, so I'm done for today.
I'll be checking tomorrow again. Basically what I have reported so far
have not strictly been translation problems specifically, but rather
things holding up issue 2883 because of making make doc fail for it.
This last problem was not really a problem of the translation branch but
rather more a combined versioning and work timing problem.
So my current focus with translation is very much getting it to stop
interfering with my current pet project. The importance of the required
changes for translation itself is sometimes dubious, so I am rather
grateful for the prompt reaction.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
Federico Bruni fedel...@gmail.com writes: Il giorno 21/ott/2012 05:17, David Kastrup d...@gnu.org ha scritto: Phil Holmes em...@philholmes.net writes: David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? I've asked on the translator list whether they want to get something translated from all the cherry-picking, and feedback is incomplete yet. Hi David, When did you ask? I may have missed your email.. I hope translati...@lilynet.net is not a dead list (or did its list server die, or is it moderated with no moderator ever approving posts?). At any rate, I sent several messages. The first I can only find in my mailing logs (Friday), but not in my mailing list archives. Too bad. Probably sitting in the translator list moderation queue. I append the second one which presumably got a reply from Francisco only because I replied to an old thread, thus directing a direct copy to him as well. The first mail mentioned the following presumably translator-relevant output (since last translation merge) dak@lola:/usr/local/tmp/lilypond$ git log origin/translation..origin/stable/2.16 --oneline Documentation d47930b Doc: extend description of glissandi (2844) 6cb3cdb Web: Add Elysium to Easier Editing section 1141313 Doc: document \time command fully (2807) dcddb2c inserted \clef treble_8 b2bdfeb Doc: delete obsolete para on two-pass spacing (2828) 6da27f9 Doc: Typos to LM - Fundamental and tweaks.itely ba92a17 Doc: extend explanation of relative-includes (2558) bcd8bd5 Doc: improve footnote documentation (2547) a885534 Doc: clarify the use of a Scheme engraver. 4239aa2 Web: Removed note about MacOS Lion not supported ac604de add website link to tunefl.com 629fc59 Doc: NR 3.2.1: clarify titles and \header blocks (2652) 5fd9cdc Fix over-long lines in glossary 44011e3 Issue 2760: CG wants all engravers to have double-quotes around them 6969857 Doc: MG: add incomplete dominant seventh chord (2749) 5b14676 Document landscape and portrait suffixes for paper size 35d565c Doc: standardise level 5 headings (2730) c586c49 Doc: added link to conversion tools from Encore to lilypond enc2ly and I am not sure the Web entries need translations (or whether it was not utterly stupid to cherry-pick them in the first place), but they _are_ compiled into local HTML and info information even if we don't display them prominently on the live web pages. I have no really good idea about the changes document. I lean to pasting a single link there to our bug tracker, listing Fixed_2_16_1 labels. I think that all translators should update the inaccuracies in LM. I'll try to do it today, even if I'm abroad and with a Windows laptop. ---BeginMessage--- If it is ok with people, I'd propose the following course in order to get the ball rolling again: I'll merge stable/2.16 into translation. That should be unproblematic. Then I'll merge translation into staging. This will require a bit of cleanup and conflict resolution. I am willing to take care of that and of the translation merges into staging when translation is still based on stable. Since one purpose of getting staging up to date with regard to translations is to be able to do extensive convert-ly work, the merging might be a bit tricky until things move over completely. I am not sure when translators will want to move their focus to master rather than stable again: it might be possible to create a branch translation-stable for working on stable branch translations, but I would like to phase out stable branch work eventually and so a separate translation-stable can still be left for a time when we feel we really need it. Probably cherry-picking will be enough if commits for unstable-only material are kept separate well enough. At any rate, with this plan it is more or less up to the translators to decide when they think 2.16.1 is ready. There is not much I cherry-picked into the stable branch since the last translation merge, and I'd not like to wait much longer than a week for 2.16.1 in consequence, but 2.16.2 will likely take quite longer. People fine with that? -- David Kastrup ---End Message--- -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
David Kastrup d...@gnu.org writes: I hope translati...@lilynet.net is not a dead list (or did its list server die, or is it moderated with no moderator ever approving posts?). At any rate, I sent several messages. At least the second one with cc to several individuals. From: David Kastrup d...@gnu.org Subject: Re: [translations] Git translation branch policy change: merge with and from stable/2.16 To: Francisco Vila paconet@gmail.com Cc: Jean-Charles Malahieude lily...@orange.fr, John Mandereau john.mander...@gmail.com, Translations list at lilynet translati...@lilynet.net Date: Sat, 20 Oct 2012 12:44:29 +0200 (21 hours, 30 minutes, 46 seconds ago) If it is ok with people, I'd propose the following course in order to get the ball rolling again: I'll merge stable/2.16 into translation. That should be unproblematic. The only reaction to that was a mail from Francisco which did not much to address this part of my plan. I did this right now, and afterwards discovered that there is a branch translation-staging. It is obvious that I suffer from a case of having not kept track of how translations are actually organized, so it may be possible that someone would need to hand-advance translation-staging to match translation, assuming that the organization of translation/translation-staging is similar to master/staging with regard to automatic testing. Ugh. Sorry for that. With the apparent lack of replies/comments/interest (possibly due to the translation list just downing any contribution from non-list-members), I felt I needed to move ahead in _some_ manner. Then I'll merge translation into staging. This will require a bit of cleanup and conflict resolution. At any rate, probably somebody who is reasonably sure to be able to write to the translators list should copy this kind of information/question there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
David Kastrup d...@gnu.org writes: I'll merge stable/2.16 into translation. That should be unproblematic. The only reaction to that was a mail from Francisco which did not much to address this part of my plan. I did this right now, and afterwards discovered that there is a branch translation-staging. It is obvious that I suffer from a case of having not kept track of how translations are actually organized, so it may be possible that someone would need to hand-advance translation-staging to match translation, assuming that the organization of translation/translation-staging is similar to master/staging with regard to automatic testing. Ugh. Sorry for that. With the apparent lack of replies/comments/interest (possibly due to the translation list just downing any contribution from non-list-members), I felt I needed to move ahead in _some_ manner. Ok, it would appear that translation had been ahead translation-staging already before my merge, so it seems I should take no guesses here and just let people who actually know what translation-staging is for deal with it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
2012/10/21 David Kastrup d...@gnu.org: I hope translati...@lilynet.net is not a dead list (or did its list server die, or is it moderated with no moderator ever approving posts?). At any rate, I sent several messages. The first I can only find in my mailing logs (Friday), but not in my mailing list archives. Too bad. Probably sitting in the translator list moderation queue. I append the second one which presumably got a reply from Francisco only because I replied to an old thread, thus directing a direct copy to him as well. Yes, you are not allowed to post on translators mailing list, in fact your email is missing from the archives. It's just because you are not subscribed, I don't think there's any moderation. We can see only the reply from Francisco: http://lilypond-translations.3384276.n2.nabble.com/Git-translation-branch-policy-change-merge-with-and-from-stable-2-16-td7572469i20.html A bit confusing, since it is an old thread and I didn't receive your email before Francisco's reply. Maybe next time write to Francisco and he will forward your message to translators list, keeping you in CC. Or ask Valentine to be subscribed (it's a low volume list). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.16.1
David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
Phil Holmes em...@philholmes.net writes: David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? I've asked on the translator list whether they want to get something translated from all the cherry-picking, and feedback is incomplete yet. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
Il giorno 21/ott/2012 05:17, David Kastrup d...@gnu.org ha scritto: Phil Holmes em...@philholmes.net writes: David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? I've asked on the translator list whether they want to get something translated from all the cherry-picking, and feedback is incomplete yet. Hi David, When did you ask? I may have missed your email.. I think that all translators should update the inaccuracies in LM. I'll try to do it today, even if I'm abroad and with a Windows laptop. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
release 2.16.1
Can you announce here the release of 2.16.1 at least a week before the actual release? So translators will have time to complete their works. I have a patch which will be ready next week and I hope it won't miss next stable release. Thanks -- Federico ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: release 2.16.1
Federico Bruni fedel...@gmail.com writes: Can you announce here the release of 2.16.1 at least a week before the actual release? So translators will have time to complete their works. I have a patch which will be ready next week and I hope it won't miss next stable release. No danger. By far the most important regressions requiring a release of 2.16.1 are the line_count fixes, and those have not been completed and have not seen exposure in an unstable release yet. I don't see the point in releasing 2.16.1 without them, so there are still at least several weeks of buffer. In the mean time, I am investigating garbage collection problems: the needs-work problems of issue 2815 URL:http://code.google.com/p/lilypond/issues/detail?id=2815 point to parts of the parse stack keeping marked objects around after their proper logical demise, possibly in areas allocated with alloca and considered released by Bison's parse stack management: this might have always been the case, or be related to other fixes I want to cherry-pick because of performance reasons, but the patch in 2815 might exacerbate it. We also have no clue about the GhostScript-related problems, but it does not appear like there is active work going on, so that is, somewhat unfortunately, not something considered delaying 2.16.1. So the collection and selection of patches into the stable branch is proceeding quite leisurely at the current point of time. I don't expect a release of 2.16.1 before end of September. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
