Re: Issues to verify
Hi Carl. - Original Message - From: Carl Sorensen c_soren...@byu.edu To: Phil Holmes m...@philholmes.net; lilypond-devel@gnu.org Sent: Tuesday, December 14, 2010 11:53 PM Subject: Re: Issues to verify On 12/14/10 10:26 AM, Phil Holmes m...@philholmes.net wrote: There are currently 8 issues to verify that could and should have been verified. I've asked the bug squad to check them, and I've been over them myself and I don't have the skills to check them. Could any developer who can, please look at http://code.google.com/p/lilypond/issues/list?can=7 and verify any that they can? Given that we're close to a release candidate, we desperately need to clear this list. Issues 1249 and 1265 require somebody who can use the Guile V2 stuff. Patrick, I think this is you, isn't it? Since it's Ian's patch, can you verify it? Issue 1365 will require somebody to check on the output of convert-ly. IIRC, Graham was heading that up. Issue 1383 will require somebody to build from source. I will do that later tonight. Issue 1386 did not have a regtest added to the distro. It's been added now. Some bug team member should validate it please. I've asked Patrick for a regtest for 1407 so that somebody can validate that issue. HTH, Carl == Thanks for helping out with this. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
DocBuild fails
Doc build is failing since yesterday evening for me. It built in w/o errors in the morning. I've committed new code locally to the CG but I don't think that's the problem. Here's the part of the log that has errors near the end: Converting to PNG...[././62/lily-b9a00701.eps] GPL Ghostscript 8.71 (2010-02-10) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Layout output to `./62/lily-b9a00701-1.eps'... Converting to `./62/lily-b9a00701-1.pdf'... Invoking `gs -dNOSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=./62/lily-b9a00701-1.pdf -c .setpdfwrite -f ./62/lily-b9a00701-1.eps'...GPL Ghostscript 8.71 (2010-02-10) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Writing ./62/lily-b9a00701-systems.texi... Writing ./62/lily-b9a00701-systems.tex... Writing ./62/lily-b9a00701-systems.count...] error: failed files: d3/lily-f0918f9e.ly de/lily-ea4526de.ly ) possibilities for f: (f fT) possibilities for fis: (fis fisT) possibilities for gis: (gis gisT) possibilities for thumb-bes: (thumb-bes thumb-besT) possibilities for thumb-e: (thumb-e thumb-eT) possibilities for thumb-fis: (thumb-fis thumb-fisT) (make-music 'UnrelativableMusic 'element (make-music 'SequentialMusic 'elements (list (make-music 'EventChord 'elements (list (make-music 'NoteEvent 'pitch (ly:make-pitch 0 0 0) 'duration (ly:make-duration 2 0 1 1)) (make-music 'NoteEvent 'pitch (ly:make-pitch 0 2 0) 'duration (ly:make-duration 2 0 1 1)) (make-music 'NoteEvent 'pitch (ly:make-pitch 0 4 0) 'duration (ly:make-duration 2 0 1 1))) (initialize #Mom -infinity )(start-trans #Mom 0 )(process-music #Mom 0 )(process-acknowledged #Mom 0 )(saw head: #Grob NoteHead coming from #Translator Note_heads_engraver )(process-acknowledged #Mom 0 )(process-acknowledged #Mom 0 )(process-acknowledged #Mom 0 )(stop-trans #Mom 0 )(start-trans #Mom 1/8 )(caught event #Prob: Stream_event C++: Stream_event((music-cause . #Prob: Music C++: Music((length . #Mom 1/8) (elements) (duration . #Duration 8 ) (origin . #location scheme-engraver.ly:74:6))((display-methods #procedure #f (rest parser)) (name . RestEvent) (types general-music event rhythmic-event rest-event)) ) (length . #Mom 1/8) (elements) (duration . #Duration 8 ) (origin . #location scheme-engraver.ly:74:6))((class . rest-event)) create: #Grob TextScript )(process-music #Mom 1/8 )(process-acknowledged #Mom 1/8 )(process-acknowledged #Mom 1/8 )(process-acknowledged #Mom 1/8 )(stop-trans #Mom 1/8 )(start-trans #Mom 1/4 )(process-music #Mom 1/4 )(process-acknowledged #Mom 1/4 )(saw head: #Grob NoteHead coming from #Translator Note_heads_engraver )(saw end of beam: #Grob Beam coming from #Translator Beam_engraver )(process-acknowledged #Mom 1/4 )(process-acknowledged #Mom 1/4 )(stop-trans #Mom 1/4 )(start-trans #Mom 3/8 )(process-music #Mom 3/8 )(process-acknowledged #Mom 3/8 )(stop-trans #Mom 3/8 )(finalize #Mom 3/8 ) | pnmtopng -compression 9 2/dev/null ./3d/lily-646e5205.png'... Invoking `gs -dEPSCrop -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -dNOPAUSE -sDEVICE=png16m -sOutputFile=./ba/lily-d51600ce.png -r202 ./ba/lily-d51600ce.eps -c quit'... Invoking `pngtopnm ./ba/lily-d51600ce.png.old | pnmscale -reduce 2 2/dev/null | pnmtopng -compression 9 2/dev/null ./ba/lily-d51600ce.png'... Invoking `gs -dEPSCrop -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -dNOPAUSE -sDEVICE=png16m -sOutputFile=./81/lily-f4727b32.png -r202 ./81/lily-f4727b32.eps -c quit'... Invoking `pngtopnm ./81/lily-f4727b32.png.old | pnmscale -reduce 2 2/dev/null | pnmtopng -compression 9 2/dev/null ./81/lily-f4727b32.png'... Invoking `gs -dEPSCrop -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -dNOPAUSE -sDEVICE=png16m -sOutputFile=./ca/lily-d3ec74cb.png -r202 ./ca/lily-d3ec74cb.eps -c quit'... Invoking `pngtopnm ./ca/lily-d3ec74cb.png.old | pnmscale -reduce 2 2/dev/null | pnmtopng -compression 9 2/dev/null ./ca/lily-d3ec74cb.png'... Invoking `gs -dEPSCrop -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -dNOPAUSE -sDEVICE=png16m -sOutputFile=./c6/lily-30600865.png -r202 ./c6/lily-30600865.eps -c quit'... Invoking `pngtopnm ./c6/lily-30600865.png.old | pnmscale -reduce 2 2/dev/null | pnmtopng -compression 9 2/dev/null ./c6/lily-30600865.png'... Invoking `gs -dEPSCrop -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -dNOPAUSE -sDEVICE=png16m -sOutputFile=./62/lily-b9a00701.png -r202
Re: lilybuntu 2
On Tue, Dec 14, 2010 at 6:32 AM, Jonathan Kulp jonlancek...@gmail.com wrote: On Mon, Dec 13, 2010 at 9:14 PM, Jonathan Kulp jonlancek...@gmail.com wrote: since most will use it in a VM. Now I'm running make all and make doc to test it before sharing. Incidentally I'd hate to have to build the Everything built without errors. I'm ready to upload the .iso. Valentin can you email me the ftp server particulars privately? Thanks. :) The new .iso file is ready. You can brows for it at this address: http://files.lilynet.net/ or download directly using this one: http://files.lilynet.net/lilybuntu2.iso http://files.lilynet.net/lilybuntu2.iso.md5 If you want to test it, please feel free. Note that the lily-git.tcl script is already in the user's home directory, ready to grab the source code. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
issue classification: priority guidelines
Hi, I've read Issue classification and i think it would be good to add one more guideline concerning priority: i believe that the priority should depend on how widespread the issue is. Even minor problems concernning some basic elements (that will probably happen many times in even a single score) should be more important than an ugly collision that came from a contrived example and is not likely to happen more often than once or twice in hundred scores, or is related to very specific and complex engraving situations. Do you agree? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
On Wed 15 Dec 2010, 12:53 Janek Warchoł wrote: Hi, Hi! I've read Issue classification and i think it would be good to add one more guideline concerning priority: i believe that the priority should depend on how widespread the issue is. Even minor problems concernning some basic elements (that will probably happen many times in even a single score) should be more important than an ugly collision that came from a contrived example and is not likely to happen more often than once or twice in hundred scores, or is related to very specific and complex engraving situations. Do you agree? I think it'd be quite difficult to make a formal rule which fit.. I use another simple rule -- if unsure, set to medium. And another -- if i'm incorrect, please correct me, i will learn this lesson. Well, probably, if i will not be corrected -- so, it's not a problem. Because i think that discussing a rule (what is minor elements, what is many times, complex situation etc) and explaining it to new bugsquadders (or reviewers, or whoever) can waste some time actually. If insure, set to medium -- by the way, please, if this is wrong, let me know .) -- Dmytro O. Redchuk Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
- Original Message - From: Janek Warchoł lemniskata.bernoull...@gmail.com To: lilypond-devel lilypond-devel@gnu.org Sent: Wednesday, December 15, 2010 11:53 AM Subject: issue classification: priority guidelines Hi, I've read Issue classification and i think it would be good to add one more guideline concerning priority: i believe that the priority should depend on how widespread the issue is. Even minor problems concernning some basic elements (that will probably happen many times in even a single score) should be more important than an ugly collision that came from a contrived example and is not likely to happen more often than once or twice in hundred scores, or is related to very specific and complex engraving situations. Do you agree? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel Here's some suggested wording picking up this suggestion and building on what we currently have: Regression- it seems to me that the distinction between regressions against 2.12 versus 2.8 as detailed in the current definitions is false. If something worked in 2.6 it should work in 2.8. If it worked in 2.8 it should work in 2.10. Und so weiter. The exception is where a feature was deliberately removed. * Priority-Critical: LilyPond segfaults, a regression against a previous stable version or a regression against a fix developed for this version. This does not apply where the regression occurred because a feature was removed deliberately - this is not a bug. * Priority-High: An issue which produces output which does not accurately reflect the input (e.g where the user would expect an accidental, but none is shown) or which produces aesthetically poor output in a situation which could be expected to crop up frequently in real-world music. It should not be used where the problem can be avoided with a simple workaround. It can also be used to flag where new code in a development version is not functioning as it should. This level is also used for issues which produce no output and fail to give the user a clue about what’s wrong. * Priority-Medium: normal priority. * Priority-Low: A minor problem which produces slightly undesirable output, or which will only occur in contrived examples, or which is very easily worked around. * Priority-Postponed: no fix planned. Generally used for things like Ancient notation, which nobody wants to touch. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DocBuild fails
Jonathan, On 15/12/2010 10:35, Jonathan Kulp wrote: Doc build is failing since yesterday evening for me. It built in w/o errors in the morning. I've built my doc with no issues, but it depends on what you call 'yesterday evening'. What is the last commit you have in your source (apart from your own local-not-yet-pushed-changes)? James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DocBuild fails
On Wed, Dec 15, 2010 at 6:40 AM, James james.l...@datacore.com wrote: Doc build is failing since yesterday evening for me. It built in w/o errors in the morning. I've built my doc with no issues, but it depends on what you call 'yesterday evening'. What is the last commit you have in your source (apart from your own local-not-yet-pushed-changes)? Here's the last commit before my local not-pushed commit: commit 91f7b40322c7f6c37bc341bf3923cade41fc Author: Carl Sorensen c_soren...@byu.edu Date: Tue Dec 14 16:43:11 2010 -0700 Add regression test for issue 1386 tablature harmonic ties -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sorry about the missing regtests
On 12/15/10 12:28 AM, Marc Hohl m...@hohlart.de wrote:
Am 15.12.2010 00:18, schrieb Carl Sorensen:
On 12/14/10 4:15 PM, Graham Percivalgra...@percival-music.ca wrote:
I only just realized that I should have done
git add input/regression/*.ly
after apply Neil's patches with patch -p1 foo.diff
Sorry about that.
Well, I don't think that either of Neil's patches included regtests. I had
regtests in my patches, but mine were (correctly) dropped. So I just added
my regtests.
I have just seen that the is a spurious tie in
input/regression/tablature-harmonic-tie.ly
after the whole note:
music = \relative c' {
s2. d\4\harmonic4 ~ |
d\4\harmonic1 ~ | % by default, tied harmonic is parenthesized
}
Is there some stuff missing (i.e. another note/a forced break) or is the
tilde
just wrong? The meaning of the comment behind this line is not clear to
me, either.
The tilde is wrong, as is the comment. The test was originally more
extensive, and the need for the rest of the test was elimminated once we
eliminated HarmonicParenthesisItem and made it part of the TabNoteHead.
I just forgot to eliminate those remnants when I eliminated the rest of the
regtest.
It's now fixed in git.
Thanks!
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DocBuild fails
Jonathan On 15/12/2010 13:19, Jonathan Kulp wrote: On Wed, Dec 15, 2010 at 6:40 AM, Jamesjames.l...@datacore.com wrote: Doc build is failing since yesterday evening for me. It built in w/o errors in the morning. I've built my doc with no issues, but it depends on what you call 'yesterday evening'. What is the last commit you have in your source (apart from your own local-not-yet-pushed-changes)? Here's the last commit before my local not-pushed commit: commit 91f7b40322c7f6c37bc341bf3923cade41fc Author: Carl Sorensenc_soren...@byu.edu Date: Tue Dec 14 16:43:11 2010 -0700 Add regression test for issue 1386 tablature harmonic ties yes, I too get the same error when trying to make ; make doc James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DocBuild fails
On 12/15/10 6:42 AM, James james.l...@datacore.com wrote: Jonathan On 15/12/2010 13:19, Jonathan Kulp wrote: On Wed, Dec 15, 2010 at 6:40 AM, Jamesjames.l...@datacore.com wrote: Doc build is failing since yesterday evening for me. It built in w/o errors in the morning. I've built my doc with no issues, but it depends on what you call 'yesterday evening'. What is the last commit you have in your source (apart from your own local-not-yet-pushed-changes)? Here's the last commit before my local not-pushed commit: commit 91f7b40322c7f6c37bc341bf3923cade41fc Author: Carl Sorensenc_soren...@byu.edu Date: Tue Dec 14 16:43:11 2010 -0700 Add regression test for issue 1386 tablature harmonic ties yes, I too get the same error when trying to make ; make doc I'm in the midst of testing with a revised regression test. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dynamic alignment
Hi Jan-Peter,
2010/12/13 Jan-Peter Voigt jp.vo...@gmx.de
Hello list,
I wrote a script to align dynamics centered on the corresponding note:
--snip--
\version 2.12.3
% calculate x-alignment based on attribute text + dynamic text
#(define-markup-command (center-dyn layout props atr-text dyn)(markup?
string?)
x-align on center of dynamic
(let* (
(text (string-append atr-text ))
(atr-stencil (interpret-markup layout props (markup #:normal-text
#:italic text)))
(dyn-stencil (interpret-markup layout props (markup #:dynamic
dyn)))
(atr-x-ext (ly:stencil-extent atr-stencil X))
(dyn-x-ext (ly:stencil-extent dyn-stencil X))
(atr-x (- (cdr atr-x-ext)(car atr-x-ext)))
(dyn-x (- (cdr dyn-x-ext)(car dyn-x-ext)))
(x-align
(* (-
(/ (+ atr-x (/ dyn-x 2)) (+ atr-x dyn-x) )
0.5) 2)
)
)
(interpret-markup layout props (markup #:halign x-align #:concat
(#:normal-text #:italic text #:dynamic dyn)))
))
% define some dynamics
pocof = #(make-dynamic-script (markup #:center-dyn poco f))
menof = #(make-dynamic-script (markup #:center-dyn meno f))
subp = #(make-dynamic-script (markup #:center-dyn subito p))
% activate X-offset, so that halign works
dynx = #(define-music-function (parser location musik)(ly:music?)
#{
\override DynamicText #'X-offset = #0 $musik \revert DynamicText
#'X-offset
#})
% example %
\new Staff
\relative c'' {
d \dynx c\pocof d e | d\ff d cis eis ~ | \dynx eis1\subp | r4 \dynx
b\menof c\f
}
--snip--
This script first calculates the widthes of the attribute-text (wa) and
the dynamic text (wd), so that I can calculate the right \halign value:
halign = ((wa + (wd / 2)) / (wa + wd) - 0.5) * 2
Then I use a markup with \halign. This works quite well as long DynamicText
#'X-offset is set! If that is set all other dynamics are aligned badly.
So I wrote a little function, that sets and unsets (reverts) that value to
let the halign work.
My question is:
Is it possible to set that value inside the make-dynamic-script or align it
some other way, so that I can simply use my defined \pocof (etc.) without
switching X-offset on and off?
Regards,
Jan-Peter
I can not answer your question, but it is probably better placed on
lilypond-devel (cc-ing).
Marek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
On Wed, Dec 15, 2010 at 12:11 PM, Jonathan Kulp jonlancek...@gmail.com wrote: The new .iso file is ready. You can brows for it at this address: http://files.lilynet.net/ or download directly using this one: http://files.lilynet.net/lilybuntu2.iso http://files.lilynet.net/lilybuntu2.iso.md5 I've added a bitTorrent tracker and server as well: http://torrents.lilynet.net Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
On Wed, Dec 15, 2010 at 12:31:02PM -, Phil Holmes wrote: - Original Message - From: Janek Warchoł I've read Issue classification and i think it would be good to add one more guideline concerning priority: i believe that the priority should depend on how widespread the issue is. Even minor problems concernning some basic elements (that will probably happen many times in even a single score) should be more important than an ugly collision that came from a contrived example and is not likely to happen more often than once or twice in hundred scores, or is related to very specific and complex engraving situations. Do you agree? No. Here's some suggested wording picking up this suggestion and building on what we currently have: Regression- it seems to me that the distinction between regressions against 2.12 versus 2.8 as detailed in the current definitions is false. If something worked in 2.6 it should work in 2.8. If it worked in 2.8 it should work in 2.10. Und so weiter. The exception is where a feature was deliberately removed. We simply do not have the resources to fix stuff that broke 4 years ago. Hence the two stable versions ago rule. As long as the bug squad does its job in checking regressions, then any *future* breakage will be reported (and therefore fixed) before the next stable version. But if anything slips through the cracks and isn't noticed for years, then I'm not going to hold up another stable release for it. * Priority-Critical: LilyPond segfaults, a regression against a previous stable version or a regression against a fix developed for this version. This does not apply where the regression occurred because a feature was removed deliberately - this is not a bug. I can't tell if there was a difference here from the current version, but this looks fine. * Priority-High: An issue which produces output which does not * Priority-Medium: normal priority. * Priority-Low: A minor problem which produces slightly undesirable * Priority-Postponed: no fix planned. Generally used for things like Ancient notation, which nobody wants to touch. Meh. Sure, whatever. Send patch to Trevor. Look, the ugly truth is that the priority field -- other than critical -- has no effect on lilypond development. I've been heavily involved since 2003 (before this issue tracker in 2006), and that's my observation. It has no statistically significant affect whatsoever. Fighting about whether a bug should be high vs. low does NOTHING to get it fixed sooner or later. This is a volunteer project, and lilypond developers do not appear to be motived based on an arbitrary priority field. The main motivating factors appear to be: 1. somebody wants that notation added (or bug fixed) for a personal score 2. it looks easy enough to attempt 3. money (i.e. if somebody offers a bounty, or hires somebody with a grant) I don't want this thread to degrade into yet another combination of rants about our development process. We have a list of GOP policy decisions, about half of which are directly aimed at improving our process. We are not going to discuss specifics of those proposals until 2.14 is out. In the mean time, go ahead and twiddle the definitions of priorities (as long as you leave Critical alone). But be aware that you're rearranging deck chairs on the titanic. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
On Wed, Dec 15, 2010 at 05:11:46AM -0600, Jonathan Kulp wrote: The new .iso file is ready. You can brows for it at this address: Great! If you want to test it, please feel free. Note that the lily-git.tcl script is already in the user's home directory, ready to grab the source code. Actually, could people wait a few days? I'd like to take this opportunity to have a thorough examination of our installation stuff. I'd like to have one person try it and make notes about what worked and what didn't, then I'll tweak the docs, then a new person will try it, then I'll adjust the docs again, etc. We have about half a dozen people using lilybuntu; if each person looks at a later draft of the instructions and we make corrections each time, we should have a bulletproof set of instructions at the end. With that in mind, could James (continue) to test it, making sure that he looks at the docs in current git rather than relying on his own knowledge? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
2010/12/15 Graham Percival gra...@percival-music.ca: In the mean time, go ahead and twiddle the definitions of priorities (as long as you leave Critical alone). But be aware that you're rearranging deck chairs on the titanic. ROTFL -- my point exactly :-) Cheers, V. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
On Wed, Dec 15, 2010 at 8:41 AM, Valentin Villenave valen...@villenave.net wrote: I've added a bitTorrent tracker and server as well: http://torrents.lilynet.net Cheers, Valentin. Excellent! Thanks Valentin. I'm set up to be a seeder. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
On Wed, Dec 15, 2010 at 1:31 PM, Phil Holmes m...@philholmes.net wrote: * Priority-High: An issue which produces output which does not accurately reflect the input (e.g where the user would expect an accidental, but none is shown) or which produces aesthetically poor output in a situation which could be expected to crop up frequently in real-world music. It should not be used where the problem can be avoided with a simple workaround. It can also be used to flag where new code in a development version is not functioning as it should. This level is also used for issues which produce no output and fail to give the user a clue about what’s wrong. I'm afraid it's far too large. If anything, we'll just have more and more High-prio issues, and less and less people to fix them, in other words this merely displaces the problem. Come on, we've alread got *five* levels of priority! That's at least one too many already (see below). * Priority-Medium: normal priority. I'd rephrase that as: Priority-Medium: problems that nobody will ever look at. * Priority-Low: A minor problem which produces slightly undesirable output, or which will only occur in contrived examples, or which is very easily worked around. I'd rephrase that as: Priority-Low: problems that nobody will ever _ever_ look at. * Priority-Postponed: no fix planned. Generally used for things like Ancient notation, which nobody wants to touch. Problems that nobody will ever, ever, EVER, have a look at. In other words, you get what I mean. recategorizing issues as High-prio just because they do affect and annoy a lot of users, is not proper development policy, it's merely pointless fluffy feelgood politics (and I'm usually the one advocating for that's kind of things, but now it would just be plain hypocrisy on our side given that we lack resources and that we perfectly know that no one will ever, ever, ever (...) look at these problems). Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
What I'm trying to do is document a categorisation that makes the job of the bug squad easier. Unless anyone says no, I'll ask for the changes proposed to be made. -- Phil Holmes - Original Message - From: Valentin Villenave valen...@villenave.net To: Graham Percival gra...@percival-music.ca Cc: Janek Warchoł lemniskata.bernoull...@gmail.com; lilypond-devel lilypond-devel@gnu.org Sent: Wednesday, December 15, 2010 2:56 PM Subject: Re: issue classification: priority guidelines 2010/12/15 Graham Percival gra...@percival-music.ca: In the mean time, go ahead and twiddle the definitions of priorities (as long as you leave Critical alone). But be aware that you're rearranging deck chairs on the titanic. ROTFL -- my point exactly :-) Cheers, V. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Regtests for 13.43
No significant changes that I can see, except the missing initial bar in the skipTypesetting tests, which is expected new behaviour. I'll run my checker when I'm not otherwise using the PC. -- Phil Holmes Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
2010/12/15 Graham Percival gra...@percival-music.ca Look, the ugly truth is that the priority field -- other than critical -- has no effect on lilypond development. I've been heavily involved since 2003 (before this issue tracker in 2006), and that's my observation. It has no statistically significant affect whatsoever. I was afraid i'll get this answer. Well, i'll have to live with that. I don't want this thread to degrade into yet another combination of rants about our development process. We have a list of GOP policy decisions, about half of which are directly aimed at improving our process. We are not going to discuss specifics of those proposals until 2.14 is out. Sure. I was also afraid of this so i asked a question about it (http://lists.gnu.org/archive/html/lilypond-user/2010-12/msg00240.html) and Phil Holmes told me to go ahead and post (http://lists.gnu.org/archive/html/lilypond-user/2010-12/msg00247.html). Fighting about whether a bug should be high vs. low does NOTHING to get it fixed sooner or later. This is a volunteer project, and lilypond developers do not appear to be motived based on an arbitrary priority field. The main motivating factors appear to be: 1. somebody wants that notation added (or bug fixed) for a personal score 2. it looks easy enough to attempt 3. money (i.e. if somebody offers a bounty, or hires somebody with a grant) Ok, this means i have to fix some (lots of?) stuff myself (you got me hooked perhaps, however i don't know how all this will turn out)... The following is for anyone interested in helping me in this task. I have some basic knowledge about C and a little experience in programming (a dozen small programs - usually less than 100 lines of code each). I have read some parts of Contributor's Guide and installed Lilybuntu (good idea! but i struggle with unbelieveably low VirtualBox resolution - 800x600, it annoys me extremely on my big monitor. Maybe i'll find an answer on the web). Unfortunately, none of the above told me what's actually happening when lilypond is run, so when i tried to look at the code, for example stem.cc, i barely understood anything :\ So if you know of any source of knowledge that may be useful for me, i'd appreciate it. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
hello, On 15/12/2010 14:58, Graham Percival wrote: With that in mind, could James (continue) to test it, making sure that he looks at the docs in current git rather than relying on his own knowledge? The iso is now downloaded. I'll look at the CG in Git (once I can compile the docs again :) I did a make doc-clean this morning) and then ran into the error Jonathan reported. Or I can use the CG on the website which seems to be Development for LilyPond 2.13.43 Is that current enough? James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
On Wed, Dec 15, 2010 at 3:48 PM, James james.l...@datacore.com wrote: Or I can use the CG on the website which seems to be Development for LilyPond 2.13.43 Actually, that's fine for you. Nothing has changed since .43 yet. I'm halfway done downloading it, and I'll make small tweaks as I go through the installation+configure myself, but I'll merge any suggestions you have into the update. I might point the next person in the list at kainhofer, once I verify that it actually has the latest version after I change stuff. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests for 13.43
Phil Holmes m...@philholmes.net wrote in message news:iealqb$3k...@dough.gmane.org... No significant changes that I can see, except the missing initial bar in the skipTypesetting tests, which is expected new behaviour. I'll run my checker when I'm not otherwise using the PC. -- Phil Holmes Bug Squad Only significant changes shown with my comparator are the skipTypesetting tests. Not only have we lost the bat mark, but the tests are somewhat further left and lower. See attached image as an example. -- Phil Holmes Bug Squad attachment: skiptypesetting-tuplet.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
2010/12/15 Janek Warchoł lemniskata.bernoull...@gmail.com: Ok, this means i have to fix some (lots of?) stuff myself (you got me hooked perhaps, however i don't know how all this will turn out)... Yes. The following is for anyone interested in helping me in this task. I have some basic knowledge about C and a little experience in programming (a dozen small programs - usually less than 100 lines of code each). I have read some parts of Contributor's Guide and installed Lilybuntu (good idea! but i struggle with unbelieveably low VirtualBox resolution - 800x600, it annoys me extremely on my big monitor. Maybe i'll find an answer on the web). Answer is in the CG in version 2.13.43. Look at the lilybuntu page right now. Unfortunately, none of the above told me what's actually happening when lilypond is run, so when i tried to look at the code, for example stem.cc, i barely understood anything :\ So if you know of any source of knowledge that may be useful for me, i'd appreciate it. 1. Everything that we have documented is in the CG. 2. Asking people about information that we haven't documented, unless you've made an obvious effort to understand it yourself first, is not going to win you friends. 3. Don't start with the hardest / highest-priority issues. Pick something tagged with frogs to get started on. You might actually want to wait a week or so, while we do a massive shake-down of the lilybuntu and compiling instructions. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
Janek On 15/12/2010 15:32, Janek Warchoł wrote: but i struggle with unbelieveably low VirtualBox resolution - 800x600, it annoys me extremely on my big monitor. Maybe i'll find an answer on the web Look in the help. 9.6. Advanced display configuration James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification: priority guidelines
On 12/15/10 8:32 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2010/12/15 Graham Percival gra...@percival-music.ca Fighting about whether a bug should be high vs. low does NOTHING to get it fixed sooner or later. This is a volunteer project, and lilypond developers do not appear to be motived based on an arbitrary priority field. The main motivating factors appear to be: 1. somebody wants that notation added (or bug fixed) for a personal score 2. it looks easy enough to attempt 3. money (i.e. if somebody offers a bounty, or hires somebody with a grant) Ok, this means i have to fix some (lots of?) stuff myself (you got me hooked perhaps, however i don't know how all this will turn out)... snip Unfortunately, none of the above told me what's actually happening when lilypond is run, so when i tried to look at the code, for example stem.cc, i barely understood anything :\ So if you know of any source of knowledge that may be useful for me, i'd appreciate it. Everything we have documented is in the Contributor's Guide. Getting started in LilyPond development is hard. Understanding how lilypond works is hard. Understanding the C++ code is hard. I wish I had better answers, but I don't. But it's not impossible. And it's fun to improve LilyPond. And when you get better answers, you can contribute them to the CG to make it easier for the next person. Section 9.1 of the Contributor's Guide gives the 30-second overview of how LilyPond works. It is, however, missing a description of the output stage, when she code that produces the postscript or svg commands is actually executed. Section 9.7 of the CG gives a rundown of a process used to trace the object relationships that might help you better understand how lilypond works. Give it a try. A debugger might help, but I find it LilyPond to be so complex in its execution that tracing it through a debugger is rarely helpful. If you search through the source code (along with studying chapter 9 of the Contributor's Guide) and then come up with specific questions about the code that you're studying, I'd expect that we'll be willing to answer them. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
keep git master clean
We have a lot of newbie contributors now. That's great! However, newbie contributors aren't confident, and aren't able to figure out why the build is failing. Especially when they're trying to build lilypond for the first time, and automatically assume that if git master can't build it's their fault. To anybody with git push ability: keep your maoing garbage off of git master. It's not fair to our young ones. This has happened half a dozen times in the past few months. That's half a dozen times too many. To anybody else with git push ability: if git master cannot compile -- either with make or make doc -- then revert the problematic commit. Don't politely ask the committer to fix it. Don't politely ask if there's a problem and start discussing it. Revert the maoing commit, and *then* start discussing how to fix it on -devel. (but make certain that the commit is actually bad -- if you suspect a build problem, then try rebuilding from scratch) If somebody reverts one of your commits, don't take it personally. We're just trying to let new contributors get started. Carl: I killed your 713aeac92c2bd06a9ae0ed38d13f4b20fba3f9a8 which was the regtest for 1440. Dunno why it was failing; building it from the command-line worked fine. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
next few weeks of development
We have one Critical issue remanining: http://code.google.com/p/lilypond/issues/detail?id=1290 I'm estimating a 4-line patch to one file. Once such a patch has been pushed, I'm branching off stable/2.14, releasing the first release candidate, and starting the two-week timer. During that period, the ONLY changes to stable/2.14 are in the translations. You might feel an urge to rush to push stuff onto master right now to get it in before 2.14.0. Don't. There will be plenty of other releases. We have way too much new stuff in 2.14.0 as it is. The world will not end if your fantastic fix is only introduced in 2.14.1. Despite the excitement about 2.14, I'm going to be working on lilybuntu and the early CG chapters since we've had a surge of new contributors. I won't be working on a patch for 1290, but rest assured that I'll do the branching and release versions when appropriate. I'm also invoking my doc meister privilege to push doc changes without review, so that we can have a quick turnaround between one person trying the instructions, me updating the instructions, and the next person trying them. This is not our usual way of working, but I think it's worth this special override of our normal policy. If I break git master, then by all means revert any of my patches without hesitation. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
hello, On 14/12/2010 03:14, Jonathan Kulp wrote: I made a new .iso with fontforge 20100501 built from source, as well as dblatex. ./autogen.sh now runs with no warnings or errors. Yes I can confirm this too. Am starting a make ; make doc now. Now if we could configure LilyGit.tcl to have another button to 'compile (doc) for the first time' It could run ./autogen.sh and then make ; make doc. I rarely make install personally. But thanks again Jonathan! James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keep git master clean
On 12/15/10 10:19 AM, Graham Percival gra...@percival-music.ca wrote: We have a lot of newbie contributors now. That's great! However, newbie contributors aren't confident, and aren't able to figure out why the build is failing. Especially when they're trying to build lilypond for the first time, and automatically assume that if git master can't build it's their fault. To anybody with git push ability: keep your maoing garbage off of git master. It's not fair to our young ones. This has happened half a dozen times in the past few months. That's half a dozen times too many. To anybody else with git push ability: if git master cannot compile -- either with make or make doc -- then revert the problematic commit. Don't politely ask the committer to fix it. Don't politely ask if there's a problem and start discussing it. Revert the maoing commit, and *then* start discussing how to fix it on -devel. (but make certain that the commit is actually bad -- if you suspect a build problem, then try rebuilding from scratch) If somebody reverts one of your commits, don't take it personally. We're just trying to let new contributors get started. Carl: I killed your 713aeac92c2bd06a9ae0ed38d13f4b20fba3f9a8 which was the regtest for 1440. Dunno why it was failing; building it from the command-line worked fine. I was just working on it. I'm sorry about the maoing garbage on master. Thanks for reverting the commit. The problem is that the snippet runs, but it generates an error (which it's supposed to do). But that error breaks the doc process. I accept responsibility for pushing the bad patch to master. It's my fault. But it also shows a severe weakness in our build system. In order to be sure a one-line patch doesn't break the build, we need to to make doc-clean make doc, which on my system takes more than an hour, and significantly slows my machine while it's working, because of all the disk access involved. And I'm supposed to do that for every patch? If so, I'm not going to do many patches. So I have a set of other practices that work most of the time, and I follow those. Occasionally, they don't work. For example, make doc works because it didn't recognize one of the changes in an input file. So I think everything works, but then it breaks on a clean build. We've got to have some better process to handle this. I don't know what it is. Maybe a correct build system, so we don't need to do make doc-clean to ensure things aren't broken. Maybe an english-only make doc, so we don't need to build all the languages when we're only working in english. Maybe a separate branch that we can push changes to and only gets moved to master once a week when it's been verified by a build-meister. I can see the problem with confusing the new contributors. And I think we should avoid it. But I also see the problem with frustrating me. Maybe I'm the only one who feels this way. But I'll just give up on submitting small patches if I have to do make doc-clean make doc for every one of the small patches. I don't have time to do it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests for 13.43
On Wed, Dec 15, 2010 at 5:17 PM, Phil Holmes m...@philholmes.net wrote: Only significant changes shown with my comparator are the skipTypesetting tests. Not only have we lost the bat mark, but the tests are somewhat further left and lower. See attached image as an example. Nooo! I can't believe we've lost the bat mark! http://ur1.ca/2li9o :-) That being said, the regtests do look better. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keep git master clean
On Wed, Dec 15, 2010 at 10:34:59AM -0700, Carl Sorensen wrote: We've got to have some better process to handle this. Agreed. I don't know what it is. For a symptomatic treatment, this particular case could be checked with make test instead of make doc. That'd be 5-10 minutes instead of an hour. Not ideal by any means, but better than nothing? Maybe a correct build system, so we don't need to do make doc-clean to ensure things aren't broken. I'm pegging this at 200 hours, and I don't think I'm overestimating. That's a lot of bugfixes, new features, CG-writing, etc. :( Maybe a separate branch that we can push changes to and only gets moved to master once a week when it's been verified by a build-meister. That's an interesting idea... I'll add it to the GOP list. If we can't find a technical solution, this might be the least-bad alternate option. I can see the problem with confusing the new contributors. And I think we should avoid it. I think the best short-term solution is: 1. accept that breakage sometimes happens. Sorry, my initial email was a bit too harsh for this. 2. accept that if a patch breaks something, revert it. No blame, no harm, no foul. Just get git master working again, then start discussing a fix. For this specific regtest, I've been building groundwork for splitting the regtests into different directories (including one for lilypond does not segfault if foo or lilypond should produce an error if bar). Once we did that, we could make sure that tests which are intended to throw an error actually do throw an error, and not balk at the compile. The butcher's bill for that idea is 40 hours, BTW. And unfortunately, all the estimates in this email are for main-developer-time, not estimated-frog-time. :( Until/unless that happens, let's just nuke the 1440 regtest. There are *so* many other things in lilypond that are worse than that one. We're in a total triage situation here. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keep git master clean
delurking for a moment ... * Carl Sorensen wrote on Wed, Dec 15, 2010 at 06:34:59PM CET: In order to be sure a one-line patch doesn't break the build, we need to to make doc-clean make doc, That simply means that there is a bug in the build system, in that it doesn't track all dependencies. The right way forward is to fix the build system, not punish (new nor old) contributors. Cheers, Ralf ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keep git master clean
On Wed, Dec 15, 2010 at 6:34 PM, Carl Sorensen c_soren...@byu.edu wrote: We've got to have some better process to handle this. I don't know what it is. Maybe a correct build system, so we don't need to do make doc-clean to ensure things aren't broken. Maybe an english-only make doc, so we don't need to build all the languages when we're only working in english. Maybe a separate branch that we can push changes to and only gets moved to master once a week when it's been verified by a build-meister. I can totally imagine having a lilypond-next branch where all the new experimental stuff happens. *And*, as I said before, I think we'd be better off branching new/stable way, way earlier. Could we have a branch Meister who'd be responsible for merging, selecting commits etc? If I were to keep working on LilyPond, I could see myself applying for that position. (But of course, someone er, reliable would be more suitable :-) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keep git master clean
* Graham Percival wrote on Wed, Dec 15, 2010 at 07:14:37PM CET: On Wed, Dec 15, 2010 at 6:09 PM, Ralf Wildenhues wrote: * Carl Sorensen wrote on Wed, Dec 15, 2010 at 06:34:59PM CET: In order to be sure a one-line patch doesn't break the build, we need to to make doc-clean make doc, That simply means that there is a bug in the build system, in that it doesn't track all dependencies. Patches appreciated. Of course. I'd love to contribute if I had time. The right way forward is to fix the build system, not punish (new nor old) contributors. Until we can trust the build system, we shouldn't consider reverting a patch to be punishment. It's just a social workaround to a technical bug which nobody has fixed (and frankly, which I doubt will ever be fixed). Right; sorry for being sloppy. I considered 'make doc-clean make doc' the punishment for (new and old) contributors, and broken git punishment for new contributors. Reversion just a workaround until the build system works, not a punishment; at least not of the person whose patch is reverted. Cheers, Ralf ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keep git master clean
On 12/15/10 10:34 AM, Carl Sorensen c_soren...@byu.edu wrote: On 12/15/10 10:19 AM, Graham Percival gra...@percival-music.ca wrote: Carl: I killed your 713aeac92c2bd06a9ae0ed38d13f4b20fba3f9a8 which was the regtest for 1440. Dunno why it was failing; building it from the command-line worked fine. I was just working on it. I'm sorry about the maoing garbage on master. Thanks for reverting the commit. The problem is that the snippet runs, but it generates an error (which it's supposed to do). But that error breaks the doc process. Oops -- I was looking at the wrong regtest. The problem with this regtest is that it creates no output, so there's no .pdf to follow up on. I'll try to get a regtest that will pass. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keep git master clean
On 12/15/10 10:57 AM, Graham Percival gra...@percival-music.ca wrote: On Wed, Dec 15, 2010 at 10:34:59AM -0700, Carl Sorensen wrote: We've got to have some better process to handle this. Agreed. I don't know what it is. For a symptomatic treatment, this particular case could be checked with make test instead of make doc. That'd be 5-10 minutes instead of an hour. Not ideal by any means, but better than nothing? So can I consider it valid if I run make doc (not make doc-clean make doc) and make test and both succeed? I'm in the midst of a make test right now. I'll get you my estimate of make test time when I'm done. Of course, in this particular case, in order to verify, I also have to do a make test-clean, because the bad regtest is part of the snippet database, and I need to purge it. Maybe a correct build system, so we don't need to do make doc-clean to ensure things aren't broken. I'm pegging this at 200 hours, and I don't think I'm overestimating. That's a lot of bugfixes, new features, CG-writing, etc. :( I think you are severely underestimating the time on this task, but that may be just because I don't understand the build system at all. I'm not advocating spending these 200 hours, by the way. Maybe a separate branch that we can push changes to and only gets moved to master once a week when it's been verified by a build-meister. That's an interesting idea... I'll add it to the GOP list. If we can't find a technical solution, this might be the least-bad alternate option. I can see the problem with confusing the new contributors. And I think we should avoid it. I think the best short-term solution is: 1. accept that breakage sometimes happens. Sorry, my initial email was a bit too harsh for this. 2. accept that if a patch breaks something, revert it. No blame, no harm, no foul. Just get git master working again, then start discussing a fix. I'm totally OK with that. I think I need to be more careful. I will try to do better. And I'm not at all offended by your original email, even if it was a bit harsh. We're all working together with one main objective -- getting 2.14 out. And it's so close I can taste it! I've got a plan for a patch to 1290 stewing in my subconscious -- I may be able to get it done next week. If I can do that, we've got a branch point! For this specific regtest, I've been building groundwork for splitting the regtests into different directories (including one for lilypond does not segfault if foo or lilypond should produce an error if bar). Once we did that, we could make sure that tests which are intended to throw an error actually do throw an error, and not balk at the compile. This would be totally cool. I was just about to ask if there is some way to manage the errors as warnings flag from inside the regtests. The butcher's bill for that idea is 40 hours, BTW. And unfortunately, all the estimates in this email are for main-developer-time, not estimated-frog-time. :( Until/unless that happens, let's just nuke the 1440 regtest. There are *so* many other things in lilypond that are worse than that one. We're in a total triage situation here. I'm also totally OK with throwing out the 1440 regtest. I was just about to do it when you did it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On Wed, Dec 15, 2010 at 11:24 AM, Graham Percival gra...@percival-music.ca wrote: Despite the excitement about 2.14, I'm going to be working on lilybuntu and the early CG chapters since we've had a surge of new contributors. I won't be working on a patch for 1290, but rest Just a reminder that I've prepared an addition to CG with steps to creation of lilybuntu and am only waiting to test doc-build after Carl's regtest is sorted. I'll push it assuming doc-build succeeds at that point. Wanted to make sure you didn't bother with that bit of the lilybuntu stuff. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
On Wed, Dec 15, 2010 at 11:50 AM, James james.l...@datacore.com wrote: Now if we could configure LilyGit.tcl to have another button to 'compile (doc) for the first time' It could run ./autogen.sh and then make ; make doc. I rarely make install personally. But thanks again Jonathan! No problem. :) I'm working on a slight improvement right now. I've made a desktop launcher for lily-git.tcl and I want to see if I can make it appear on the user's desktop by default instead of in the home directory. Trying to make it as foolproof as possible for a new user. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
On Wed, Dec 15, 2010 at 7:40 PM, Jonathan Kulp jonlancek...@gmail.com wrote: I'm working on a slight improvement right now. I've made a desktop launcher for lily-git.tcl and I want to see if I can make it appear on the user's desktop by default instead of in the home directory. Trying to make it as foolproof as possible for a new user. Err... I think that's reached the point of diminishing returns. If somebody can't figure out how to open up the Places-home and double-click on lily-git.tcl , then it might be more merciful to discourage them from trying lilybuntu at all. Now, if you're curious about this, then by all means go ahead. But I don't think it's worth updating the 1.2gig iso image just for this. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On Wed, Dec 15, 2010 at 6:24 PM, Graham Percival gra...@percival-music.ca wrote: You might feel an urge to rush to push stuff onto master right now to get it in before 2.14.0. Don't. There will be plenty of other releases. We have way too much new stuff in 2.14.0 as it is. The world will not end if your fantastic fix is only introduced in 2.14.1. I get your point, I really do. However there's a bunch of patches that have been sitting there for a while: off the top of my head, http://codereview.appspot.com/74056/ http://codereview.appspot.com/224052/ http://codereview.appspot.com/1659041/ http://codereview.appspot.com/1878048/ http://codereview.appspot.com/1880050/ http://codereview.appspot.com/1914043/ http://codereview.appspot.com/1983047/ http://codereview.appspot.com/2020041/ http://codereview.appspot.com/2145047/ (I feel bad about this one) http://codereview.appspot.com/2219044/ http://codereview.appspot.com/2220041/ (yes) http://codereview.appspot.com/2726043/ http://codereview.appspot.com/3334043/ ... and that's but what I could come up with with a quick search on Rietveld. Do we really want to ship a new version without at least giving these a more proper look? I for one, couldn't care less whether my vaporware acciaccatura/NoteNames/HairpinText patches go unmerged for several stable versions to come. But loosing other people's patches is definitely something we don't want, even when their authors themselves seemingly loose interest in getting them merged. I'm also invoking my doc meister privilege to push doc changes without review, so that we can have a quick turnaround between one person trying the instructions, me updating the instructions, and the next person trying them. This is not our usual way of working, but I think it's worth this special override of our normal policy. Way to go! Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On 12/15/10 12:15 PM, Jonathan Kulp jonlancek...@gmail.com wrote: On Wed, Dec 15, 2010 at 11:24 AM, Graham Percival gra...@percival-music.ca wrote: Despite the excitement about 2.14, I'm going to be working on lilybuntu and the early CG chapters since we've had a surge of new contributors. I won't be working on a patch for 1290, but rest Just a reminder that I've prepared an addition to CG with steps to creation of lilybuntu and am only waiting to test doc-build after Carl's regtest is sorted. Graham's reversion solved the doc-build problem. I'm currently in the middle of a make-doc for a revised 1440 regtest. When it's done I'll push a replacement regtest. You can grab the current git and do your test right now. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilybuntu 2
On Wed, Dec 15, 2010 at 1:46 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Dec 15, 2010 at 7:40 PM, Jonathan Kulp jonlancek...@gmail.com wrote: I'm working on a slight improvement right now. I've made a desktop launcher for lily-git.tcl and I want to see if I can make it appear on the user's desktop by default instead of in the home directory. Trying to make it as foolproof as possible for a new user. Err... I think that's reached the point of diminishing returns. If somebody can't figure out how to open up the Places-home and double-click on lily-git.tcl , then it might be more merciful to discourage them from trying lilybuntu at all. Hehe probably right about that. Now, if you're curious about this, then by all means go ahead. But I don't think it's worth updating the 1.2gig iso image just for this. :) Can you tell I'm on winter holiday? ;) I'm having fun fiddling around learning this stuff. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On Wed, Dec 15, 2010 at 1:56 PM, Carl Sorensen c_soren...@byu.edu wrote: Just a reminder that I've prepared an addition to CG with steps to creation of lilybuntu and am only waiting to test doc-build after Carl's regtest is sorted. Graham's reversion solved the doc-build problem. I'm currently in the middle of a make-doc for a revised 1440 regtest. When it's done I'll push a replacement regtest. You can grab the current git and do your test right now. Thanks Carl, I'm in the middle of a make-doc after doing exactly as you said. Assuming it compiles without errors, do I do: git push origin or is it something else? It's been over a year since I pushed any code and I can't remember. Don't want to mess it up. I already did git commit -a and made a commit message. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On 12/15/10 1:24 PM, Jonathan Kulp jonlancek...@gmail.com wrote: On Wed, Dec 15, 2010 at 1:56 PM, Carl Sorensen c_soren...@byu.edu wrote: Just a reminder that I've prepared an addition to CG with steps to creation of lilybuntu and am only waiting to test doc-build after Carl's regtest is sorted. Graham's reversion solved the doc-build problem. I'm currently in the middle of a make-doc for a revised 1440 regtest. When it's done I'll push a replacement regtest. You can grab the current git and do your test right now. Thanks Carl, I'm in the middle of a make-doc after doing exactly as you said. Assuming it compiles without errors, do I do: git push origin I do git push origin master to limit the push to my master branch. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On Wed, Dec 15, 2010 at 08:56:15PM +0100, Valentin Villenave wrote: However there's a bunch of patches that have been sitting there for a while: off the top of my head, I really hope you just did a label:patch search in the issue tracker to find that liast. Do we really want to ship a new version without at least giving these a more proper look? Yes. Because the VERY FIRST gop policy debate is about how we deal with patches. (yes, I'll make an agenda, and I'm open to changing the order of stuff in general -- but I'm going to insist that patches is the very first thing) But loosing other people's patches is definitely something we don't want, In most cases, we've already lost those patches. Don't cry over spilt milk. Let's get 2.14 out the door, then start fixing our development policies so that it doesn't happen again. I have a plan. We have the manpower. We can fix it. Look, if an old patch can still be applied cleanly to current git, then we'll almost certainly be able to apply it to git in 3 weeks from now. And if an old patch *doesn't* apply cleanly to current git and nobody wants to fix it, then 3 weeks from now, it still won't apply to git and somebody will need to fix it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On Wed, Dec 15, 2010 at 02:24:15PM -0600, Jonathan Kulp wrote: Thanks Carl, I'm in the middle of a make-doc after doing exactly as you said. Assuming it compiles without errors, do I do: you read the lily-git.tcl section in the CG. git push origin or is it something else? ... if you have git push access (which I think you do), and if you haven't changed anything since last year, then yes. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On Wed, Dec 15, 2010 at 2:35 PM, Graham Percival gra...@percival-music.ca wrote: ... if you have git push access (which I think you do), and if you haven't changed anything since last year, then yes. Got it. Pushed. Thanks guys, Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On Wed, Dec 15, 2010 at 9:33 PM, Graham Percival gra...@percival-music.ca wrote: I really hope you just did a label:patch search in the issue tracker to find that liast. Nope. Some of these are untracked. Yes. Because the VERY FIRST gop policy debate is about how we deal with patches. Do you realize how many questions/issues this has been your sole answer to in the past few months (if not years)? :-) In most cases, we've already lost those patches. I'm sure you're jumping to conclusions here. Deeming these as lost is exactly what makes them lost. Don't cry over spilt milk. Mmm, let me guess, this is your way of /not/ being offensive, right? :-) I have a plan. We have the manpower. We can fix it. Aye aye. insert epic background music here Look, if an old patch can still be applied cleanly to current git, then we'll almost certainly be able to apply it to git in 3 weeks from now. And if an old patch *doesn't* apply cleanly to current git and nobody wants to fix it, then 3 weeks from now, it still won't apply to git and somebody will need to fix it. I'm not planning to be around in three weeks. So, just sayin'. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On 12/15/10 12:56 PM, Valentin Villenave valen...@villenave.net wrote: ... and that's but what I could come up with with a quick search on Rietveld. How did you do your search on Rietveld? I've never been able to find a decent method to search Rietveld. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sorry about the missing regtests
On 14 December 2010 23:18, Carl Sorensen c_soren...@byu.edu wrote: On 12/14/10 4:15 PM, Graham Percival gra...@percival-music.ca wrote: I only just realized that I should have done git add input/regression/*.ly after apply Neil's patches with patch -p1 foo.diff Sorry about that. Well, I don't think that either of Neil's patches included regtests. Indeed. Neither patch was ready for applying (which should have been done using the --author option). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: next few weeks of development
On Wed, Dec 15, 2010 at 10:25 PM, Carl Sorensen c_soren...@byu.edu wrote: How did you do your search on Rietveld? I've never been able to find a decent method to search Rietveld. There isn't. All I could do was to browse the user's pages for a few known associates of the LilyPond project: e.g. http://codereview.appspot.com/user/Neil%20Puttock (btw: interestingly, you're the only one who hasn't a proper user page. How come?) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
