Re: GOP-PROP 2-1: LilyPond is part of GNU

On 05/07/12 01:27, Graham Percival wrote: Thanks for checking! I'm following up on ripple and NW2LY Re NW2LY, I think you'll be OK if NW2LY itself is free software (but it didn't seem so to me?) and it is referred to as a solution to help users extract their music from a proprietary program.

Re: GOP2-3 - GLISS or not

On 24/07/12 10:09, Graham Percival wrote: Let’s decide whether to try to stabilize the syntax or not. What type of project do we want LilyPond to be? What kinds of guarantees (or at least firm intentions) do we want to give to users with respect to lilypond 2 or 5 years from now being able to rea

Re: GOP2-3 - GLISS or not

On 26/07/12 16:50, David Kastrup wrote: Joseph Rushton Wakeling writes: How feasible is it for LilyPond to support a deprecation mechanism for syntax? At some time, it will be removed or the warning is pointless. So this will not address the topic of bitrot for large mostly dormant bodies

Re: GOP2-3 - GLISS or not

Just realized I sent my original reply straight to Graham and not to the list -- sorry for the double email :-( On 26/07/12 19:19, Graham Percival wrote: I should add some more context. I've just remembered that we have a tutorial (don't ask me how I forgot), and that covers pretty much what I

Re: GOP2-3 - GLISS or not

On 27/07/12 11:11, Graham Percival wrote: Think of the stable notation as a subset, not the complete set. Yes, fair enough -- it's very likely changes can be done additively and if not for the traditional syntax to be maintained as syntactic sugar. Hmm. I'll have to think about this more.

Re: GOP2-3 - GLISS or not

On 30/07/12 17:52, Graham Percival wrote: In general, yes. But some aspects of our syntax haven't been around for a long time -- footnotes, woodwind fingering, compound meters, etc. Do we have the best syntax for those? I mean, maybe David can figure out a way to allow us to write \compound

Re: GOP2-3 - GLISS (final)

On 10/08/12 02:23, David Kastrup wrote: It would have been 3+2/8 at any rate since throwing parens into the token syntax would have further messed up the ambiguities, and forms like 3/2+2/5 would not likely have worked. Could it improve matters to have instead something like, 3:2 + 2:5 ...

Re: GOP2-3 - GLISS or not

On 10/08/12 15:06, Reinhold Kainhofer wrote: I haven't looked at the code, but I don't see a reason why it wouldn't be possible to extend that to non-power-of-2 denominators. Great! :-) What's odd is that it already works for some cases, but not others -- examples attached to the bug report h

Re: [GLISS] differentiating pre/post/neutral commands

On 01/09/12 17:25, Graham Percival wrote: Continuing to brainstorm on the problem of it not being obvious to which note a particular \command refers to, what if we used: \postfix: c2 d\p is unchanged /prefix: for music functions like c2 /parenthesize d .neutral: for commands which aren't

Re: [GLISS] differentiating pre/post/neutral commands

On 03/09/12 21:12, David Kastrup wrote: Graham Percival writes: The hard and fast rule is "- attaches to a note; = attaches to the prevous element". I don't think that we had a chance to get into that during the big meeting. "the previous element" is the same kind of thing. c-.=\parenthesiz

Re: how to make decisions?

On 03/09/12 14:18, David Kastrup wrote: I don't have a good answer here, and I am not particularly happy with suggesting that the work I end up doing will not likely be shaped much by committee or community decisions but rather mostly by my own conscience and programmer instincts. Which, in turn

Re: how to make decisions?

On 06/09/12 11:48, Graham Percival wrote: What's depressing? I didn't see anything unusual in those comments. I suppose it's a bit depressing that no one pointed out why it matters that you enter exact pitch names and don't infer accidentals from the key signature. (I.e., how do you copy-pas

Re: [GLISS] why the hell all this fuss

I'm moving this discussion from -bug to -devel as it seems more appropriate here. On 06/09/12 11:56, David Kastrup wrote: Joseph Rushton Wakeling writes: Has anyone ever actually engaged with any major publishers to identify the factors that are of interest to them in engraving sof

Re: Heinrich Ignaz Franz Biber

On 08/09/12 10:17, Werner LEMBERG wrote: due to the discussion about funny accidental placements in music written for strings with scordatura, I had a closer look at the Rosary Sonatas from Biber. As a result, I'm playing the 14th sonata with my daughter in a concert[1], among other pieces :-)

Re: [GLISS] why the hell all this fuss

On 08/09/12 16:10, Han-Wen Nienhuys wrote: I have in the past talked with people from Henle; also, Schirmer has a style guide that you can order as a book. How far in the past are we talking about? (Just for clarity.) My overall impression is that they are primarily interested in: * Strict

Re: [GLISS] differentiating pre/post/neutral commands

On 11/09/12 13:04, David Kastrup wrote: Basically every construct that we would be tempted to use <> or s1*0 for occasionally is one that is not really attached to a note, but rather to a moment in time. You can put it in parallel music without changing results. Most articulations with a shorth

Re: [GLISS] differentiating pre/post/neutral commands

On 11/09/12 14:15, David Kastrup wrote: No. Just those commands that are not intrinsically attached to a note within a voice, like dynamics and phrasings. Basically those things that you'd occasionally attach to <> or s1*0 for lack of something more suitable. In the case of dynamics, you real

Re: [GLISS] non-timed or non-musical events "z" "y"

On 13/09/12 08:11, David Kastrup wrote: If it does, so does << c'1 { s4 s\< s2 s\! } >> Stepping back from syntax for a second, the problem with the above (as currently implemented) is that the spacing will not produce correct output from a visual engraving point of view. This applies also

Re: [GLISS] non-timed or non-musical events "z" "y"

On 17/09/12 13:38, David Kastrup wrote: So what would be required here seemingly would be linearization of the spacing in absence of note columns which convey proper timing through their note values, however non-linearly spaced. Actually, this is an interesting question for people to examine in

Re: [GLISS] non-timed or non-musical events "z" "y"

On 23/09/12 00:07, Graham Percival wrote: I have no problem with splitting \tempo into a \tempo_bpm and \tempoMark command. Or perhaps it would be better to just use \mark, and add markup functions which mimic the "text" parts of the existing \tempo command (if they don't already exist, which th

Re: [GLISS] non-timed or non-musical events "z" "y"

On 23/09/12 15:58, David Kastrup wrote: With the separately discussed "isolated durations are pitch-less NoteEvent in noteentry", you could use arguments like { 8 ~ 8. } = { 4 } and such music arguments would get passed through a \score markup using a specific TempoStaff without stafflines and wi

Re: [talk] easy tuplets

On 24/09/12 18:27, David Kastrup wrote: I don't like it since it does not match musical concepts. You would not talk about "12th notes" to other musicians. That's not entirely true. Contemporary composers (I think Ferneyhough started it, others have continued it) have used time signatures li

Re: [talk] easy tuplets

On 25/09/12 06:48, Keith OHara wrote: Try it out. Enter some Debussy using 12th-notes, 9th notes, etc. If nested tuplets are your intended testing ground, try engraving Ferneyhough. All else is playground stuff. :-)

Re: [GLISS] basics

On 24/09/12 14:07, Janek Warchoł wrote: I suggest to ask more for complaints than for ideas: what users find confusing, inconvenient and difficult to express in Lily syntax. I think this will be more valuable information than proposals "let's have a syntax like this". Actually, rather than "wh

Re: [GLISS] basics

On 26/09/12 09:19, Janek Warchoł wrote: This is a good idea in itself, but i'm afraid we'll drown in the flood of suggestions if we ask this question now. Currently we want to focus on syntax alone. I do understand that, it's just that I think that proposals for syntax changes make more sense

Re: [GLISS] basics

On 27/09/12 16:44, Janek Warchoł wrote: oh yes, that's on my list of "difficult to express" things for more than a year. Reading Keith Stone's contemporary music examples, you'll see there's a similar issue for glissandi with a terminating pitch ... :-) _

Re: [talk] easy tuplets

On 25/09/12 18:03, James wrote: PAH! I bet Mike Solo would eat Ferneyhough for breakfast If you mean Mike Solomon then yes, his scores engraved with Lilypond are mightily impressive. :-) ... but for the problem at hand -- in the scores I've seen, he doesn't use the complex nested tuplets o

Re: [talk] easy tuplets

On 27/09/12 19:15, Ian Hulin wrote: It's slightly off-topic from Graham's original proposition in the thread base-message, which was restricted to multiple-of-two/multiples-of three type duplets. This part of the thread has strayed beyond extra valid values for durations, and we've strayed into

Re: [talk] easy tuplets

On 27/09/12 21:06, m...@mikesolomon.org wrote: From my Suite Post Algorithmica. I stand corrected, and rather amused :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [talk] why it'd be great to have web interface for submitting simple doc patches

On 10/06/2012 11:34 AM, James wrote: How is a web interface easier than email to enter information? Well, the problem with simple doc patches is that to submit them to Lilypond you have to go through the same procedure as if you were submitting a code patch, which means uploading to Riedveld

Re: [proposal] easy triplets and tuplets - was [talk] easy tuplets

On 10/05/2012 09:31 AM, Keith OHara wrote: It is easier to keep the order straight if you write a 5:4 tuplet as \tuplet 5/4 {} Is there any reason why you couldn't write \tuplet 5:4 {} ... ? Keeps exact match between musical and Lilypond syntax and avoids the potential mental block of having

Re: [talk] why it'd be great to have web interface for submitting simple doc patches

On 10/06/2012 04:46 PM, James wrote: Says someone who evidently has never built, submitted or tested 'doc' patches for LP. Er ... yes, I have. Actually my objections to having to use git-cl were based on my experience of trying to submit a simple, small doc patch that I'd built and tested.

Re: [talk] why it'd be great to have web interface for submittingsimple doc patches

On 10/06/2012 05:21 PM, Phil Holmes wrote: Unfortunately, testing that docs compile cleanly takes about 15 times as long as code, so it's not for the underpowered or faint hearted. Used to be 2 3/4 hours on my virtual machine. Yes, true. The from-scratch build time for docs is pretty hefty, t

Re: [talk] why it'd be great to have web interface for submittingsimple doc patches

On 10/06/2012 05:46 PM, Phil Holmes wrote: As you say, compile-edit-compile cycles are shorter than the full build, but can occasionally not reveal errors, so for a proper test it's always better to nuke the build directory and rebuild from scratch. Out of curiosity, what kind of errors? I ima

Re: [proposal] easy triplets and tuplets - Draft 3

On 10/07/2012 05:04 PM, Ian Hulin wrote: The design was deliberately restricted to providing shorthands for the \times commands with 2:3 and 3:2 ratios expressed in the n/m rational parameter, however there seemed to be a feeling that the 5:4 ratio was just as common. (See 6. above). Yes, it i

Re: [proposal] easy triplets and tuplets - Draft 3

On 10/07/2012 11:29 PM, Reinhold Kainhofer wrote: http://lsr.dsi.unimi.it/LSR/Item?id=482 http://lsr.dsi.unimi.it/LSR/Item?id=817 I implemented those functions for MusicXML import. Note, however, that lilypond does not automatically use those, you have to manually set them as shown in the snippe

Re: [proposal] easy triplets and tuplets - Draft 3

On 10/07/2012 11:52 PM, Reinhold Kainhofer wrote: There is, however, no check whether the fraction with the durations makes sense and matches the real tuplet (in most cases, itwill not). Yes, that's what I mean. I'd like to see something where the fractions and durations are all derived from

Re: [proposal] easy triplets and tuplets - Draft 3

On 10/08/2012 12:40 AM, David Kastrup wrote: I diasagree. Whether or not you we provide separate commands actually doing the overrides, the choice between all those variants does not appear to convey musical information individually but just constitutes a different choice of consistent notation

Re: [proposal] easy triplets and tuplets - Draft 3

On 10/08/2012 01:03 AM, Reinhold Kainhofer wrote: Actually, thinking of it, it would actually be quite simple to calculate the displayed fraction with durations from the given durations and the tuplet fraction (except that there is no way to distinguish 3:2 and 4:6). (m*dur1):(n*dur2) = tuplet f

Re: LilyPond 2.17.4 released

On 10/07/2012 01:22 PM, David Kastrup wrote: I'd rephrase the first two sentences as This version contains work in progress. Only users who are prepared to deal with crashes or unexpected ... +1 I think this is the best way to characterize it. You might want to rephrase it slightly to make

Re: [proposal] easy triplets and tuplets - was [talk] easy tuplets

On 10/08/2012 01:29 PM, James wrote: I have the good fortune to play with semi-professionals and also teachers who when I queried said [I paraphrase], well sure I guess you could technically call them that, but 'no one really does' and besides when do you stop calling them their numerically accur

Re: [proposal] easy triplets and tuplets - Draft 3

On 10/08/2012 10:44 PM, Janek Warchoł wrote: First, we shouldn't mix content and presentation. I think it's a very important rule; one of the best things in LilyPond is that she allows to separate music from its layout. Yes, fair point. But one thing to be careful of particularly as regards

Re: [proposal] easy triplets and tuplets - Draft 3

On 10/08/2012 11:25 PM, Thomas Morley wrote: But once I saw a bigband-part for guitar, notated with changing clefs between bass and treble. Well, it was the real treble, no transposition. That it was the real treble was only understandable from the context. The real stupidity there is surely th

Re: [proposal] easy triplets and tuplets - Draft 3

On 10/09/2012 01:12 AM, Graham Percival wrote: On Mon, Oct 08, 2012 at 11:49:39PM +0100, Trevor Daniels wrote: Absolutely! Inverting the fraction for \tuplet was the original reason for inventing it, IIRC. Woah, really? I thought the whole point was to avoid the confusion between \time and \

Clefs and transposition [was: Re: [proposal] easy triplets and tuplets - Draft 3]

On 10/09/2012 05:23 PM, Janek Warchoł wrote: As for transposing clefs, i play guitar a bit myself, and i have once typeset a piece using both G and G_8 clefs. Maybe it was a bad idea, but for me it was perfectly fine. Yes, definitely a bad idea. Use 8va. brackets instead when you want to

Re: Clefs and transposition [was: Re: [proposal] easy triplets and tuplets - Draft 3]

On 10/10/2012 12:08 AM, Joseph Rushton Wakeling wrote: Yes, definitely a bad idea. Use 8va. brackets instead when you want to send everything up an octave like that. It was fine for _you_ because you wrote it and knew what you wanted anyway, but it would have probably been confusing for

Re: [proposal] easy triplets and tuplets - Draft 3

On 10/10/2012 09:52 AM, David Kastrup wrote: However, forcing a certain form of input representation for a certain form of output is a nuisance for programmatically generated music. I'd rather recommend using something separate like \tupletStyle "3:2", \tupletStyle "3", \tupletStyle "". That's

Re: stepping down as project manager

On 10/13/2012 11:44 PM, David Kastrup wrote: \once creates a one-time-step temporary change, \temporary an unterminated temporary change which can be terminated element-wise with \revert or, again using a converter, en bloc from the original overrides with \undo. Forgive me for coming into this

Re: Lilypond Feta font license

On 10/18/2012 09:38 AM, Han-Wen Nienhuys wrote: The idea behind this is twofold: first, the GPL does not make sense for a font. That's not entirely true. Obviously it's not a good condition for use of a font in a document, and you _can't_ copyright the _appearance_ of the font, but it makes

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

On 03/13/2013 12:22 AM, Janek Warchoł wrote: this reminds me of an idea i had that would probably play nicely with this: make it possible to manipulate hairpins' ends separately. The point would be that you could specify a vertical offset for one end and thus easily achieve a slanted hairpin (wit

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

On 03/17/2013 05:28 PM, m...@mikesolomon.org wrote: > My suggestion was flairpin, which is infinitely cheesier and thus way cooler. I know, but ... at the end of the day, less clear in meaning than either ferneyhough-hairpin or flared-hairpin. Sad but IMO true. :-P _

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

On 03/17/2013 06:47 PM, thomasmorle...@googlemail.com wrote: > And while above the staff dynamic brackets have the hook down. As I said before, I'd have argued for that feature even in the absence of a Ferneyhough example, as it makes musical/notational sense. But I think the example settles it.

Re: Suggestions for participating institutions?

On 03/26/2013 11:52 AM, Han-Wen Nienhuys wrote: > Take in mind that EU research programmes come with an incredible > amount of burocracy and require both academic and industry partners, > the more the merrier. The projects that get funded are buzzword > compliant, but often nobody knows what they s

Re: Suggestions for participating institutions?

On 03/26/2013 06:27 PM, David Kastrup wrote: > It might even make sense to try getting Steinberg on board. They have > just acquired the old Sibelius developers. Now the focus I see for > LilyPond itself is bringing it into line for operating it with a growing > corpus of public domain music. We

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

On 05/09/2013 02:52 PM, zepadovani.li...@gmail.com wrote: > just installed 2.17.17 and it seems that the new (and nice!) angled > hairpins are not compatible with the circled tip I think this should be considered a bug, as the two notations are clearly compatible. ___

Doc build hanging (with memory leak?)

Hello all, I've successfully build Lilypond itself from source, but when I try to make doc, the build hangs on the first file it attempts to compile: make[3]: Entering directory `/home/joseph/code/lily/build/input/regression' LILYPOND_VERSION=2.15.39 /usr/bin/python /home/joseph/code/lily/scr

Re: Doc build hanging (with memory leak?)

On 12/05/12 11:59, Phil Holmes wrote: The doc build now issues far less "chatter" than it used to. With a single core machine, it could well go an hour without a single message. If it's using CPU and taking memory, be patient. If there's no response after a day, let us know. OK, cool. It's nic

Re: Doc build hanging (with memory leak?)

On 12/05/12 13:37, David Kastrup wrote: You are running a command - echo texi2html not found and that does not quite work. It would appear that the error handling for a missing texi2html script is totally awful. I'd install texi2html and rerun configure. Texi2html was already installed

Re: Doc build hanging (with memory leak?)

On 12/05/12 14:29, James wrote: Assuming you are building from current master then make doc does compile as all new checkins go to staging tree first and sit there while a script runs (as it happens on my computer) that compiles staging through all the tests and if it passes them all (and that in

Re: Doc build hanging (with memory leak?)

On 12/05/12 17:22, James wrote: On 12 May 2012 14:24, Joseph Rushton Wakeling A small word to this effect might be a nice addition to the contributor guide (I'll make a patch if you like). Sure go ahead. Here you go. :-) Let me know if it needs tweaking or might be better in an

Re: Plan for discussions

On 13/05/12 23:34, Graham Percival wrote: LilyPond itself will remain as a command-line "compiler". So this question can be split into two separate ones: - what capabilities should alternate programs (i.e. frescobaldi) have? - what should the input syntax be? When considering these question

Re: Doc build hanging (with memory leak?)

On 14/05/12 07:35, Graham Percival wrote: On Mon, May 14, 2012 at 03:38:54AM +0200, Joseph Rushton Wakeling wrote: Here you go. :-) Let me know if it needs tweaking or might be better in another section of the guide. Please see the "summary for experienced developers" in the

Re: Plan for discussions

On 14/05/12 07:37, Graham Percival wrote: No. LilyPond is a command-line "compiler". That's something that would happen in an alternate program. I'm not disputing that, or suggesting that you go into GUI/IDE territory directly -- what I'm suggesting is that consideration be given to what mig

Re: Doc build hanging (with memory leak?)

On 14/05/12 09:46, David Kastrup wrote: We don't have a canonical developer, one whose personal branch/repository would be official for the project. GitHub and Launchpad both permit branches to be owned by groups as well as individuals. I'm sure other DVCS-based code hosts do as well, but tho

Re: Plan for discussions

On 14/05/12 09:56, David Kastrup wrote: http://lilypond.org/doc/v2.15/Documentation/source/Documentation/notation/skipping-corrected-music> Yes, but that wasn't the use-case I had in mind. The sort of thing I was thinking of was: (i) I have a full, complete score, which I have compiled.

Re: Doc build hanging (with memory leak?)

On 14/05/12 11:41, David Kastrup wrote: Before saying anything more, I'm sorry if my earlier email was offensive or intemperate; it wasn't meant to be. I was writing out of concern for the ease of contributing to LilyPond (more on that in a moment). Have you actually used Rietveld for re

Re: Plan for discussions

On 14/05/12 11:47, m...@apollinemike.com wrote: This is very hard because of the butterfly effect - an A-flat in an already-crammed line could lead to new line breaking, which means new vertical spacing etc.. I don't assume it would be easy! But enabling GUI/IDE developers to build function

Re: Doc build hanging (with memory leak?)

On 14/05/12 14:15, David Kastrup wrote: They are treated by the bug squad picking up the suggestion and filing it in the issue problem. If someone suggested to you that they will refuse doing that, that someone was not giving you correct information. OK. :-) To be fair, reconsidering things,

Re: Plan for discussions

On 14/05/12 14:36, David Kastrup wrote: It is not like the graphical frontends are not mentioned in LilyPond's documentation. Have you checked http://lilypond.org/doc/v2.15/Documentation/web/easier-editing#Score_002c-tab-and-MIDI-editors_003a>? Personally I'm a Frescobaldi fan. MuseScore is a

Configuring git-cl

Hello all, When running git cl config, it asks for more info than I have found in the current contributors' guide. Yes, I can/could just hit a newline, but it'd be nice to have concrete answers -- what are the correct pieces of info for: * Tree Status URL (I put the URL of the LP git repo

Re: Configuring git-cl

On 15/05/12 16:35, Graham Percival wrote: On Tue, May 15, 2012 at 02:19:34PM +0200, Joseph Rushton Wakeling wrote: Yes, I can/could just hit a newline, but it'd be nice to have concrete answers -- what are the correct pieces of info for: quick answers here It seems fine to just hit

Re: GOP-PROP 2-1: LilyPond is part of GNU

On 19/06/12 13:32, Graham Percival wrote: do not recommend any non-Free programs, nor require a non-free program to build 13 I’d better check the licenses of the “Easier editing” programs. If you mean the list here: http://lilypond.org/easier-editing.html ... there are 2 proprietary prog

Re: References to publications in the docs

On 07/13/2013 02:11 PM, Federico Bruni wrote: > It was ignored from the very beginning (perhaps a kind of todo list): Pretty much. At the actual time of writing there was some discussion of whether or not to include info on interesting scores to look at, the general feeling was against, but no co

Re: References to publications in the docs

On 07/13/2013 07:52 PM, Mark Polesky wrote: > Personally, I'd prefer to remove all mention of Gardner > Read's book. Many of his recommendations are not good at > all, and I've found a fair number of them that are just > wrong. Better to say that it's out of date. But its datedness is one reason

Re: we now have "lilypond" organization on GitHub

On 22/09/13 17:53, David Kastrup wrote: Yup. So we are talking about creating untested patches here that eventually travel into the usual testing pipeline we use. The main GitHub-hosted project that I'm involved with has auto-testing set up for pull requests, that's obviously integrated to so

Re: we now have "lilypond" organization on GitHub

On 23/09/13 14:15, David Kastrup wrote: GitHub's usage conditions are so aggressively proprietary and disenfranchising that it's not suitable for our regular processes. They reserve the right of shutting accounts and projects down if they don't like their bandwidth usage or for any other reason.

Re: we now have "lilypond" organization on GitHub

On 23/09/13 03:16, Graham Percival wrote: The experience from the Grand Documentation Project is that only 25% of new doc contributors ended up being a net benefit. Having an up-front hurdle, provided that it's well-explained, is a useful way to weed out people who are likely to fall into the re

Re: we now have "lilypond" organization on GitHub

On 22/09/13 17:21, Phil Holmes wrote: IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly in a Virtual Machine) provides git and git-cl. Git allows a developer to create a patch with 2 commands: git commit and git format-patch. That can be uploaded to Rietveld with a sin

Re: we now have "lilypond" organization on GitHub

On 23/09/13 08:59, David Kastrup wrote: It may be that something like Gitorious would obsolete Gerrit (as well as the Google issue tracker), but then we need to start somewhere. Gitorious has no in-built issue tracker. I think the normal thing is to integrate it with a project-specific Trac i

Re: we now have "lilypond" organization on GitHub

On 23/09/13 14:15, David Kastrup wrote: At any rate, I think the first thing we would likely want to experiment with would just be Gerrit. May be useful to you, if you haven't already read it: http://feeding.cloud.geek.nz/posts/code-reviews-with-gerrit-and-gitorious/ _

Re: we now have "lilypond" organization on GitHub

On 24/09/13 13:58, David Kastrup wrote: Well, the usage conditions prohibit mimicking them, but then I have my doubts that this will stand before a court. So the worst that can happen realistically is that they kick you out. Which they can for any reason at all anyway. Hmm, I'd like to see th

Re: we now have "lilypond" organization on GitHub

On 24/09/13 14:09, David Kastrup wrote: You _are_ aware that the _majority_ of current contributors is running Windows? Try setting up a native development environment for LilyPond on Windows. Come back when you are done. What is the reason for it being so difficult? and the risk is that us

Re: we now have "lilypond" organization on GitHub

On 24/09/13 14:14, Graham Percival wrote: Umm, the whole point of the VM is to ensure that the contributor's setup is *right*. As far as I can see, the whole point of the VM is to get round the fact that the range of environments you can use to hack on Lilypond is severely restricted. I'm su

Re: we now have "lilypond" organization on GitHub

On 24/09/13 14:22, Graham Percival wrote: Suppose somebody sends you a bad patch that would take you 5 minutes to re-implement from scratch. Do you: 1) spend 30 minutes explaining how to fix the patch 2) tell them to go screw themselves 3) ignore the patch silently and give the person no indica

Re: we now have "lilypond" organization on GitHub

On 24/09/13 14:22, Graham Percival wrote: I've done #1. I spent a WHOLE YEAR doing #1. It was an experiment. I was absolutely committed to teaching people how to do docs. However, #1 gives a net penalty of 25 minutes. One thing to add. I completely get how frustrating and annoying it must

Re: we now have "lilypond" organization on GitHub

On 24/09/13 15:34, Phil Holmes wrote: I imagine that one problem of using a VM is that it makes it much more difficult/slow to run such local tests? Not with current servers. GUB is built in a VM, much faster than most people could do it natively. Running on servers, sure. I was thinking o

Re: we now have "lilypond" organization on GitHub

On 24/09/13 15:41, David Kastrup wrote: What about "Try it" did you not understand? Windows does not just allow you to say sudo apt-get build-dep lilypond Instead you have several dozens of dependencies you have to satisfy by hand, and then the fun with registry entries and other stuff st

Re: we now have "lilypond" organization on GitHub

On 24/09/13 15:45, David Kastrup wrote: "you" is you. So start fixing it. You know better than everybody else what is in need of fixing, so go ahead. Every time I raise usability issues related to the contribution tools, I run into this big wall of denial that there is actually a problem. A

Re: we now have "lilypond" organization on GitHub

On 23/09/13 12:59, Graham Percival wrote: Reviewing patches? Explaining why we reject a patch (I don't think we can fairly reject a patch unless we explain why)? Those are significant costs. What are the most common reasons for doc patch rejection? __

Re: we now have "lilypond" organization on GitHub

On 24/09/13 17:05, David Kastrup wrote: No, you are not just "asking". You are throwing diagnoses around and proposing solutions that are known not to work. I keep asking you questions because I want to correct my ideas and impressions if they are wrong. Still, I'm curious -- what is it ab

Re: we now have "lilypond" organization on GitHub

On 24/09/13 17:10, Phil Holmes wrote: Poor syntax; poor explanation; unnecessary; failure to compile; failure to follow standards. OK. What are the typical patch-reviewer reactions to each of these? ___ lilypond-devel mailing list lilypond-devel@gn

Re: we now have "lilypond" organization on GitHub

On 24/09/13 18:05, James wrote: The fact our documentation is (even if I do say so myself) very comprehensive, is precisely because patches get reviewed and discussed before they are incorporated (this wouldn't happen with a wiki). Things like users reporting typos and simple changes often get fi

Re: we now have "lilypond" organization on GitHub

On 24/09/13 18:19, Janek Warchoł wrote: Whatever is meant by those saying it, at the end of the day it comes across as: "Hey, we don't care about your usability issues, we don't care that it's difficult and finnicky to contribute to us, we only care about solving that problem if you solve it for

Re: we now have "lilypond" organization on GitHub

On 24/09/13 18:59, David Kastrup wrote: How about not worrying about the tools then and just doing your contribution any old way you prefer to work? We have procedures in place for picking up from there. I can give a detailed response here, but ... it's got a bit heated today. Shall we pick

Re: we now have "lilypond" organization on GitHub

On 24/09/13 20:16, David Kastrup wrote: Well, let's just say that our track record with "I'll contribute once everything is exactly like I want it, I could not expect to bother you with my help before" is not unlike that spelled out in Wilde's "The Devoted Friend" http://www.online-literature.com

Re: improving our contributing tools and workflow

On 26/09/13 12:26, David Kastrup wrote: The dean is annoyed: "Why can't you be like the mathematicians? They just need pencils, paper, and a wastebasket and will work for years. And the philosophers don't even need a wastebasket..." Not any more, either for mathematicians or philosophers ... :

Re: improving our contributing tools and workflow

On 26/09/13 14:26, David Kastrup wrote: So Graham organized the infrastructure where this would not easily happen again in the same manner, and the Contributor's Guide reflects it. But we haven't exactly seen a flurry of patches from newcomers appearing on the lists. Of course, part of the reas

Re: improving our contributing tools and workflow

On 26/09/13 13:56, Phil Holmes wrote: As far as I'm concerned, Google Code could be changed. I find its restriction on attachments annoying. However, a replacement would have to be able to import _all_ the issues lodged there with all their detail and attachments, and provide similar facilities

Re: improving our contributing tools and workflow

On 26/09/13 11:48, Janek Warchoł wrote: David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? GitLab: http://gitlab.org/ Looks more feature-complete and user-friendly than Gitorious (it's go

Re: improving our contributing tools and workflow

On 26/09/13 14:52, Phil Holmes wrote: I thought I made this clear - I was repeating something Graham said to me on a number of occasions. He would argue it was realistic, not pessimistic. You have to be aware of the fact that, simply by working hard on a problem does not guarantee that the effor

  1   2   >