Re: [PATCH] Change autobot comment from LGTM to passes tests.
On Mon, Apr 30, 2012 at 02:26:41PM +0200, David Kastrup wrote: Turns out I don't seem to have push privileges: What's your github username? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Change autobot comment from LGTM to passes tests.
On Mon, Apr 30, 2012 at 03:25:56PM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: What's your github username? I don't think I have an account at github. You may wish to consider making one, given how many lilypond sub-projects are there: https://github.com/gperciva (gub, git-cl, lilypond-extra, lilypad; the other four are not related to lilypond) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Change autobot comment from LGTM to passes tests.
On Mon, Apr 30, 2012 at 04:12:37PM +0200, David Kastrup wrote: Well, I can always submit patches. I don't really fancy registering with services that claim that they can change terms of use without announcement, with any subsequent use signifying consent to the changed terms. oh, I wouldn't use them for anything other than git. But the beauty of distributed version control is that you can drop a server the instant anything fishy happens. I basically use them as a cheap way of synchronizing between machines. Anyway, no big deal either way. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
built dist failure
file from VC not distributed:
lilypond-2.15.38/Documentation/web/server/tweets.xml
rm -rf /tmp/tmpuq4W6b
Traceback (most recent call last):
File test-lily/dist-check.py, line 137, in module
main ()
File test-lily/dist-check.py, line 132, in main
check_files (tarball, repo)
File test-lily/dist-check.py, line 117, in check_files
raise Exception ('dist error found')
Exception: dist error found
make[3]: *** [unlocked-dist-check] Error 1
make[3]: Leaving directory `/main/src/gub'
make[2]: *** [cached-dist-check] Error 2
make[2]: Leaving directory `/main/src/gub'
make[1]: *** [dist-check] Error 2
make[1]: Leaving directory `/main/src/gub'
make: *** [lilypond] Error 2
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spanish pondings
On Fri, May 04, 2012 at 02:33:05PM +0200, m...@apollinemike.com wrote: On 4 mai 2012, at 14:29, Francisco Vila wrote: 734f525 Web-es: Really make Spanish Pondings work. 278124f Web-es: make Spanish Pondings work. Are those changes too invasive? Yes. I don't think it's a good idea to have translations for pondings. I'm putting them up in whatever language they're sent to me. The only two that exist for the moment are in English, but they can certainly be in Spanish, in which case everyone will see them in Spanish. I agree. In fact, seeing pondings in other languages could be a nice touch and a reminder that lilypond is used internationally. If you really want a particular piece of news to appear in multiple languages, then just send in multiple translations to be included in the normal tweets.xml file. Then they'll appear randomly just as any other ponding. I'd therefore suggest that all pieces of news appear in English plus any other applicable languages. Mike, could you push a new ponding about your thing in French? Also, could you make the font size slightly smaller? at the moment it's bigger than our what is lilypond text. I'd say it should be one or two notches smaller. (interpret notch as whatever makes sense for web fonts) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On Sat, May 05, 2012 at 10:35:02AM +0200, Federico Bruni wrote: Il 25/04/2012 12:04, Graham Percival ha scritto: [..] I'm trying to learn Python and I'd like to contribute to some frog tasks requiring python (I've starred some frog issues in the tracker). Probably this is too much difficult for a newbie. Currently, makelsr.py adds different amounts of blank lines to some .ly files depending on whether you run it as a full import vs. when you run it locally. It would be nice if that didn't happen. I think that blank lines are not the only problem. Of course it isn't. But it's the *easiest*, most *harmless*, way that you could get started. It's not an urgent job. Once somebody knows python and that script, it's a 5-minute job to fix it. That's why I thought it would be perfect for you to start with. As a general rule of thumb, 5 minutes of experienced developer time translates to about 5 hours for a complete beginner. If you're not a complete beginner at python and the script, then reduce the estimate according to however you rank your own skill. -snip- Does it make sense? It's plausible, but I really don't know how the system works. You could try asking John Mandereau. I still think you should start with an easy job, but if you want to jump straight into the hard stuff, go ahead. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Development status of midi output in 2.15.38
On Sat, May 05, 2012 at 09:57:07AM +0700, Michael Pozhidaev wrote: After the last announce I have tried the linux x86_64 binary package of lilypond-2.15.38 to see what is going to be in 2.16. It works but I met some regressions in midi output comparing with 2.14.2 currently I am working with. It seems to me this problem should be already known, so I just would like to ask is the midi output needs further development and I should just to wait more? There are no known Critical regressions since 2.14.2. If you have found one, then please send a tiny example to the bug list. Critical regressions are defined as output which is unintentionally worse. It is possible that there were some deliberate changes to the midi backend (in which case they should be noted in the Changes document). But until we see a specific tiny example, we can't comment further. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Substitute for s1*0
On Sun, May 06, 2012 at 08:58:11AM +0100, Trevor Daniels wrote: David Kastrup wrote Sunday, May 06, 2012 2:57 AM In fact, isn't generally prettier than s1*0? Should we be using it in code and documentation rather than s1*0? Definitely prettier, but maybe not so transparent as s1*0. +1 What about defining a null or n note name? Then we could write c4 n\footnote - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Your Gnu package lilypond
On Sun, May 06, 2012 at 05:15:59AM -0400, John Darrington wrote: Thank you for your very comprehensive reply, which inspired me to look at the lilypond website. It is indeed very elaborate and certainly gives a very professional impression. (There are however a few terminology issues which I think need attention - See section 14 of the GNU Maintainers guide http://www.gnu.org/prep/maintain/maintain.html ) Janek, how about you fix this. I found one instance: http://lilypond.org/freedom.html has a big Free Software at the top. The only place open source is mentioned is almost at the bottom of the page, in the quote “Gift culture”: the Free Software (or “Open Source”) movement has created many great software projects, such as GNU/Linux, Mozilla Firefox, and Battle for Wesnoth. Having benefitted from these projects, some developers want to “give back” to the community. I suppose that you're objecting because I wrote or in there, and you would rather that I replace that or with sometimes erroneously referred to as ? but you should review the rest of the website to see if there's any other terminology issues. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to remove a file
On Sun, May 06, 2012 at 05:32:08PM +0200, Federico Bruni wrote: I made a try: $ git rm Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc error: 'Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc' has local modifications (use --cached to keep the file, or -f to force removal) What's the recommended method? Use -f to force removal? Yes, that's recommended. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
translators: fix your open source mistranslations
I have a bit more information about the terminology problems. Although the English website is relatively ok (I remember specifically thinking about free software vs. open source while writing it -- but Janek should still fix the little bits I missed), some translations are wrong. For example, On Sun, May 06, 2012 at 11:30:19AM -0400, John Darrington wrote: My system happens to be set up in a German locale, so I see the German translations by default. On the front page I see: LilyPond ist ein Open Source-Programm In fact it seems that in many (all?) places Free Software has been mistranslated as Open Source. Free software and open source do not mean the same thing; if in doubt, find some official GNU guide on translations or something. We have historically not had much to do with GNU, but it seems that we're moving into an era where we have closer ties. This will mean a bit of extra administrative work to match unavoidable GNU policies. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Intregrating lilypond.pot update to 'make release'
On Sun, May 06, 2012 at 06:19:42PM +0200, Jean-Charles Malahieude wrote: What you'll find in the enclosed patch is an attempt to adapt 'make po-replace' in order to have an automatically well-formed .pot included in 'make dist'. Please upload patches to rietveld with git-cl, as specified here: http://lilypond.org/doc/v2.15/Documentation/contributor/summary-for-experienced-developers With specific regards to the release, I would need a patch to the CG release process instructions: http://lilypond.org/doc/v2.15/Documentation/contributor/minor-release-checklist For reliability, I never deviate from this checklist. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: translators: fix your open source mistranslations
On Sun, May 06, 2012 at 07:02:20PM +0200, Jean-Charles Malahieude wrote:
Just two instances in GSoC node that I'm not sure they should be
transformed:
fr (translation)]$ git grep -n 'open source'
web/community.itexi:930:étudiants pour écrire du code au bénéfice de
projets @emph{open source}.
web/community.itexi:931:Google a travaillé de concert avec la
communauté @emph{open source} afin
Hmm. The English version is a direct quote from google's website,
and of course one should never change direct quotes. Now if
you're translating the quote for some reason, then I guess you
should try to keep as close to the original meaning as possible...
and in google's case, they definitely mean open source instead
of free software.
So I guess those shouldn't be changed, and if that's it in the
French translation then I guess you're fine.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: translators: fix your open source mistranslations
On Sun, May 06, 2012 at 09:36:38PM +0200, Francisco Vila wrote: 2012/5/6 Graham Percival gra...@percival-music.ca: So I guess those shouldn't be changed, and if that's it in the French translation then I guess you're fine. We have in English http://lilypond.org/freedom.html “Gift culture”: the Free Software (or “Open Source”) movement has created... Yes, I've asked Janek to fix that one. http://lilypond.org/reviews.html “Wonderful free (open source) software [..] I think the first is wrong; the second is an exact quote from something wrong. Yes. ok, I've just looked at the home page in every language, and the only one that appears to say open source is German. *shrug* I guess it was just bad luck that a German GNU person looked at the website? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Substitute for s1*0
On Sun, May 06, 2012 at 10:17:05PM +0100, Trevor Daniels wrote: I've no objection to the docs being changed to use an empty chord but its semantics will need to be introduced somewhere. The best place is probably the LM, in 2.2.4 Combining notes into chords. I'm still not happy with an empty chord, especially in the Learning Manual. I think it leads to the perlization of lilypond, where we end up looking like a ridiculous language like Haskell. I'm ok with using as a quick hack for things like convert-ly rules, so I'm not arguing against David's patch. But I wouldn't want to see becoming part of our basic vocabulary. I still think that a n or z or \null would be more clear if there's a solid reason to have such a musical event in a non-computer-modified score. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Substitute for s1*0
On Mon, May 07, 2012 at 11:00:39AM +0200, David Kastrup wrote:
James pkx1...@gmail.com writes:
Evidence? 'skip' is exactly what it says on the tin.
But we are not talking about \skip (which actually would have the
advantage of _not_ tampering with the current duration in the parser,
and the disadvantage that it does not take post-events and thus is
totally pointless for this task) but s. s says nothing on the tin, you
need to look it up in the manual on its own.
wait, \skip and s aren't the same thing??
Leaving that question aside, we're talking about the preferred
method of having something which does not tamper with the current
duration but does take post-events.
A number of people think that is the ideal tool for a
non-duration post-event. James and I disagree; we think that a
different tool (such as a new \null or \nullevent) would be easier
to read.
I absolutely take Graham's point that having a not uncommon sytax
expression like ' a4.(\-\[^\markup {hello} \\ ...' is ugly
Reality check. is not new. And it is not what makes the above look
bad.
Seriously? wow, we have radically different standards of
readability.
Uh, (or ) is precisely that: a chord. Which is the reason that it
works. Are you arguing that we should abolish chord syntax?
No, we're not suggesting that we abolish chord syntax. But we
*are* suggesting that a different method of indicating a
non-duration post-event would be preferrable, and if we have such
a method, we shouldn't encourage the use of for that task.
Why would we suddenly become familiar with over s1*0?
Because we already _are_. We are not talking about a proposed change in
functionality. We are talking about a proposed change in documentation.
I gave an example where s1*0 causes _totally_ unexpected results.
Please stop the straw-men. Nobody thinks that s1*0 is the best
method of indicating a non-duration post-event.
Are you
really holding a grudge because of the one-time comment from Janek
Please stop the ad-hominen attacks. James and I are not holding
any grudges.
Also isn't this a really a GLISS topic?
Reality check. has already worked for eternities. It would be GLISS
to _disallow_ it. I can see no reason for that.
We're not proposing that we _disallow_ it. We're proposing that
there might be a better way, and if we can agree on a better way,
it would be good not to encourage the method.
Should we also disallow using { } and instead of \sequential and
\simultaneous (which have been available since LilyPond 1.1 but do not
see much use)?
Now you're just being ridiculous.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Substitute for s1*0
On Mon, May 07, 2012 at 11:04:50AM +0100, Ian Hulin wrote:
Hi all,
Point of information:
On 07/05/12 10:29, Graham Percival wrote:
A number of people think that is the ideal tool for a
non-duration post-event. James and I disagree; we think that a
different tool (such as a new \null or \nullevent) would be easier
to read.
Except \null has already been used as \markup command. I know
you can distinguish by context, but your argument here is about
readability.
Ok, I forgot about that, but \nullevent would still work -- or
even just \event, or \timeless, or something along those lines.
You would really need a colour syntax-highlighting facility like
in Frescobaldi to make the distinction clear.
or just pick a different word.
introduce a \placeholder
command which hardly anyone will use with the docstring
I'd be ok with a \placeholder.
This produces an event in the music stream that does not affect
note-spacing in the visual output from LilyPond, nor does it affect
the default note-duration in the parser. It is commonly abbreviated to
the empty chord symbol @code{}. It is commonly used to attach
markups and similar items where there may not always be a real note to
which to attach the item
Delete that commonly abbreviated sentence and I'd be all for
that. If it's implemented internally as that's fine, provided
we have a regtest that ensures that
c4 \placeholder\whatever d4
works properly.
Also isn't this a really a GLISS topic?
1+
We're discussing preferred syntax.
Yes.
*shrug*
We could postpone this discussion, or try to formalize this, or
just declare that whoever can push whatever they want with the
understanding that the whole debate will be re-opened when GLISS
happens and the syntax may change.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ponding croaks
On Mon, May 07, 2012 at 10:05:45AM +0200, David Kastrup wrote: m...@apollinemike.com m...@apollinemike.com writes: It's important that these things lend credibility to LilyPond. Yes. Not necessarily time-specific, either. IMO something like The East Anglican Choir of Upper North-West Sussex performs chorales typeset with LilyPond every Sunday is fine. Hm. Sounds like my croaks are more like pondings for the manual rather than the front page. ... How would those differ from the snippets? I'm fine with a browse 10 random snippets option in LSR. I'm even fine with the idea of automatically loading a few random snippets on lilypond.org using some javascript hack. (in theory, at least -- there are technical issues to consider) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Substitute for s1*0
On Mon, May 07, 2012 at 08:54:49PM +0100, James wrote: On 7 May 2012 20:32, Nicolas Sceaux nicolas.sce...@gmail.com wrote: Now that this is settled, Oh that's ok then. I'll get my coat. Yep. I don't understand why David's proposition, which is both cheap and neat, faced such opposition. I, for one, will be using the new idiom. With all due respect it faces opposition by someone who doesn't code, doesn't know what a 'parser' is or looks like, doesn't know what an alist is, doesn't know the difference between a grob and engraver a textscript or markup, doesn't know ... etc. The more alien you make the syntax the more it puts people off. Agreed. *shrug / sigh* Look, we've lost this argument -- and yes, I use the term lost and argument advisedly. I am *not* happy with how nasty this thread has gotten and the lack of respect we appear to have for each other's viewpoints. I'm going to delete all remaining emails about this matter without reading them, because I have better things to do than to have my concerns belittled. I'll have to be even more cautious when running GLISS than I was initially planning. I'm not at all looking forward to it... and frankly, my motivation to do *anything* for lilypond is approaching an all-time low. Good thing I'm going on vacation tomorrow. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Plan for discussions
Spent yesterday wandering around Kloten, the old town part of Zurich, and looking at stain-glass windows. Spent this morning walking along Uetliberg, a series of hills right next to the city. Travel advice: skip the city and culture, just go straight to the Alps. Ok, maybe Uetliberg isn't high enough to qualify as alps, but the basic idea is the same -- cities aren't worth the trouble; the vertically-based wilderness is the place to be. Anyway. We need an avenue for structured discussions. Technical questions have a firm right or wrong -- a piece of code either leaks memory or it doesn't; a slur either collides with a finger or it doesn't. That type of discussion needs no special handling; in the very worst case, anybody involved can simply run the code and see the same results on their own computer. (or if the code runs differently, then the discussion can/will usefully shift to investigating the cross-platform problems) But policy and human-computer interaction questions lack objective answers. How often should we have stable releases? It depends on how we view the software, what kind of assurances we want to provide to users, what kind of reputation we want, etc. Depending on what we choose, we may have more (or fewer) questions on the mailing list, more (or fewer) new contributors, more (or less) morale of the existing developers, etc. There's no obviously correct answer, and even if we agreed on all the factors we should consider, every person involved would give different weights to each factor. Even worse, we don't have a firm plan on how to deal with these questions. My impression is that we don't mind postponing something if there's a clear reason to do so, as long as there's some assurance that it will be done -- and ideally, an exact date at which it will happen. So here's what I propose: in the summer we'll re-start the Grand Organization Project discussions, and also start GLISS. In June, we will begin GOP2 discussions with the same format as last year: I will post an initial discussion email which opens the topic, gives an overview of the options and their benefits and costs, and possibly includes a tentative suggestion. (this may be written by somebody other than me, but I will still schedule the discussions as well as check that a topic has enough info such that we can have a reasonable discussion about it) The discussion will last for one week to ideally reach consensus, then I'll summarize the discussion and the current proposal. There will then be a second week for second thoughts or additional debate. If everything has settled by the end of the second week, we accept that proposal; if not, we'll either extend the discussion or abandon/postpone the proposal. There's some doubts about some of the policy decisions we made last year, either because a topic didn't gather enough interest and slipped in, or because we have more information now than we did last year. For that reason, we'll revise everything. First two questions: 0. we are a GNU project. (not open to debate, just a re-affirmation of fact, plus a longer examination+discussion of exactly what that means) 1. release policy -- when should we have a stable release? In July, we will begin GLISS, almost certainly in the same format as GOP. Initial Discussion questions will try to be as general as possible -- for example, instead of arguing if we should have \hideNotes vs. \notesHide, we will discuss the general question of noun-verb vs. verb-noun command names (a third option would be to decide to have no general policy on this issue and treat everything on their own individual merits, but I hope we don't take this decision because that leads to a ton of discussions). Hopefully we can settle a good chunk of questions at once in that manner. My supervisor for my Masters degree often noted that HCI (human-factor interaction) conferences have the nastiest discussions in all of Computer Science -- if you're at a conference on data structures then people are really nice and positive and try to give useful advice to each other, whereas HCI discussions tend to rip each other apart. I've noted a similar thing in music academia -- the more subjective the subject, the more personal the participants take the debate. It's an understandable human response that is seen in any number of venues. For that reason, I'm going to try to keep the GLISS discussions as focused as possible. That's why I'm reserving an extra month before starting it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plan for discussions
On Fri, May 11, 2012 at 09:59:49AM +0200, Janek Warchoł wrote: On Fri, May 11, 2012 at 9:19 AM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: What about a real-life meeting? There will be a GNU conference in Dusseldorf (west Germany) in second half of July, maybe we could meet there for a couple of days and sort out some big picture stuff? I think that discussing LilyPond live for one day will give us better results than a month of mailing lists discussions. I could offer accommodation and discussion room (and accordions) for a few people in Waltrop, rural location about 50 miles from Düsseldorf (10 miles from Dortmund). Wait, we're all metric, right? 80 and 15 it is, then. There is a piano here as well, but its tuning is sort of rural, too. Oh, and Internet of course. Hm, there would be a guitar somewhere that is, while not fabulous, also not exactly supermarket trash. A master keyboard too, and several Midi expanders. And reasonable room. Cool! That's something like +100 from me :) That's a very nice offer from David, and it would be great if we could take him up on it, either in July or August. However, I am opposed to any official (GOP or GLISS) proposals being decided at such a venue. We have developers and contributors around the world, and it would be horribly unfair to people in Brazil or Australia if 3-4 people gathered in Germany and decided stuff. Such a venue could be absolutely wonderful for technical matters (be they bugfixes, new features, or updating docs to match program behaviour). However, I would urge that such work still go through the normal countdown process. On a mundane organizational level, the patches could go straight to a dev/waltrop branch (without countdowns), and then over the next week(s) the commits from that branch would be considered (and if necessary re-worked) for staging. Similarly, we could have informal discussions about GOP or GLISS issues, to find out what the main concerns and options are. However, the result of that discussion would merely be a better introduction to the debate (i.e. write the question in a clearer manner, prepare additional materials so that people can examine some graphical output, prepare a report about bugs reported or git commits, etc. I don't want to discourage the gathering at Waltrop, especially since I've wanted to hire (or rent or whatever the term is) a horseback ride for ages, but just consider how you'd feel if I met Colin Campbell at the Calgary Stampeed and we decided what the final solution to the s1*0 would be. You'd be pretty pissed off at us, and justifiably so! I agree that email discussions can lead to additional misunderstandings, long latency, and can be frustrating, but they are the fairest way to conduct such business with our international team. Even a simple IRC or skype chat is difficult to coordinate; it is virtually impossible schedule one for a dozen people, and we have more than a dozen people who will be interested in GOP and GLISS questions. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plan for discussions
On Fri, May 11, 2012 at 01:57:08AM +0200, Janek Warchoł wrote: i suggest to discuss some communication guidelines, for example don't say It's settled then until there's more than 1 day of discussion and not all concerns have been addressed, even if you think that the decision is obvious. I think last year's GOP communications guidelines were sufficient. How exactly do you suggest to change them, and why? What were the problems with GOP? Also, how do we treat partial/imperfect/temporary solutions? On an ad-hoc basis? I don't know how else we can do it. Should we accept it or not? Depends on the patch. Can we discuss bigger changes in syntax, too? I mean, not just the naming of commands (of course that's needed), but also the stuff that is related to how things work inside Lily. For example syntax for overriding broken spanners, context-id-specific overrides, etc. The first run of GLISS will probably not involve any tweaks or overrides, but we'll see how it goes. i'm afraid that discussing really big structural changes in LilyPond (which are necessary imho) over e-mail will take sooo much time that it'll be very ineffective. As said elsewhere, I am not aware of any viable alternative that is sufficiently inclusive for our developer community. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plan for discussions
On Fri, May 11, 2012 at 08:20:57PM +0200, Jean-Charles Malahieude wrote: May I propose a workaround, just in order to mix business with pleasure: Why not trying to have one meeting per continent at the same time, with a daily hour on IRC with everybody? We tried that almost a year ago: http://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00131.html but if you want to try organizing it again, that would be great! Potentially it could even start small by having a mainly-French irc or skype session (my impression is that you guys are more close-nit than other lilypond developers/contributors), then once that's a regular occurance try to expand it? Of course it would be nice if it could immediately start off with everybody involved, but the previous experience doesn't fill me with optimism. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc build hanging (with memory leak?)
On Sat, May 12, 2012 at 01:56:33PM +0200, Joseph Rushton Wakeling wrote: On 12/05/12 13:37, David Kastrup wrote: 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, but re-running configure revealed that dblatex was missing (for some reason aptitude build-dep lilypond didn't include that). huh, thanks for the report. http://code.google.com/p/lilypond/issues/detail?id=2529 - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: LoMus 2012
On Sat, May 12, 2012 at 02:53:58PM +0200, Janek Warchoł wrote: On Sat, May 12, 2012 at 12:37 PM, David Kastrup d...@gnu.org wrote: Make a ponding of the award, and point to the contest site (if any) for the details. Like the awarded sum. I'd find it weird to flash numbers on our main website. I think this qualifies for a news item - after all, it's *LilyPond* who won. Graham? sure. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: commit access
On Fri, May 11, 2012 at 11:28:47PM +0200, Benkő Pál wrote: dear team and Project Manager, I'd like to get commit access. Make an account at savannah, and send a request via the savannah project page. I'll act on it within 48 hours (wifi connection at this hotel isn't the greatest). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plan for discussions
On Sat, May 12, 2012 at 02:14:27PM +0200, Janek Warchoł wrote: I think it's about the big picture stuff and general design. At the moment, i don't see any vision that we - The LilyPond Development Team - have about how the future of the project should look like, oh, I definitely have a vision for that. what changes in the LilyPond design should we make to make LilyPond a more efficient and easy to use tool. 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? The latter question will be covered by GLISS. i suggest to discuss some communication guidelines, for example don't say It's settled then until there's more than 1 day of discussion and not all concerns have been addressed, even if you think that the decision is obvious. I think last year's GOP communications guidelines were sufficient. Hmm? I recall only one decison: Potentially sensitive or private matters will be referred to Graham. (GOP 6) It's only partially applicable to the problems we sometimes have in our discussions (in my opinion). I meant the general method of me announcing a discussion, waiting a week, summarizing the discussion, waiting a week, then moving forward. For other things, there's the countdown process. It sounds like you want to have something in between a normal countdown and a GOP item. The first run of GLISS will probably not involve any tweaks or overrides, but we'll see how it goes. What do you mean by tweaks and overrides? The syntax of these commands itself, i.e. whether we should require #s or not? Anything involving a \tweak or \override or \set or \with or similar commands. I have an idea about syntax that would affect bot regular and tweak syntax, and it doesn't make much sense to discuss it in two parts because the logical connection would be lost. Well, I'm trying to find some way of focusing discussion. So imagine that you want to typeset the simplest possible music that it still reasonable -- say, a solo cello Bach suite. Single-staff, (mostly) monophonic, (mostly) diatonic, etc. Can we finalize on input syntax to represent such pieces? Maybe that's *too* focused, so consider a slightly harder version. A Beethoven violin suite? Thats violin + piano, but still pretty simple as far as a semantic description of the music. Can we devise an input syntax that we can confidently agree to support with no changes? Maybe bump up the complexity by one more level -- maybe a voice+piano work? Mid-romantic? Schubert, perhaps? I suspect that this alone will take 6 months at least, but it would still be a solid step forward, especially with respect to other projects creating lilypond notation. Once those changes have stabilized and we have a break of a few weeks, we'll look back at how the process worked for that goal, and plan the next phase accordingly. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc build hanging (with memory leak?)
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 CG. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plan for discussions
On Mon, May 14, 2012 at 03:51:45AM +0200, Joseph Rushton Wakeling wrote: 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 questions, can some attention be given to the possibilities of real-time update to the score output, as the code is tweaked? No. LilyPond is a command-line compiler. That's something that would happen in an alternate program. Consideration will be given to overall compile speed, but that's it. A really intelligent editor could only update sections of the score at once (via the clip or skipMeasures functionality), but again that's back to alternate program territory. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Mon, May 14, 2012 at 03:07:23PM +0200, John Mandereau wrote: Ok, this time I got $ cat /home/lilydev/lilypond-auto-compile-results/log-2012-05-14-14.txt Begin LilyPond compile, commit: c597a126f11943be74a98efee056ab54ae729315 Merged staging, now at: c597a126f11943be74a98efee056ab54ae729315 I wouldn't expect those to be the same, but perhaps that's just some iffiness due to playing around with the setup. Success:pushed to master I hope it had the desired action, I'm not willing to run it again until being up to date with development policies. Looks good. Development policies (or practice) for patch merge-stable is to run the script every 6 hours. That should be it. If there's a failure, email goes to lilypond-devel. If there's a success or failure, email goes to lilypond-auto. That should all be set up automatically (provided you have a good config file). James: could you disable your cronjob, then let John set up a cronjob or run it manually for a few days? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plan for discussions
On Mon, May 14, 2012 at 01:51:42PM +0200, Joseph Rushton Wakeling wrote: 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 functionality like that *shrug* the source is available. Those GUI/IDE developers can talk to us. Of course the easiest way to go about this would be to enable a bad line breaks mode, where it compiles the score once, then when you change something, it only recompiles that system (with the bar numbers for the beginning and ending of each system being cached). That alone would be a huge time-saving. *shrug* as I've said, the source is available. Interested developers are welcome to talk to us. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plan for discussions
On Mon, May 14, 2012 at 09:52:32AM +0200, Joseph Rushton Wakeling wrote: 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 might help enable such an alternative program. E.g. can LP be in a position to permit an IDE to perform efficient background compilation, enabling it to update as you type, and to alert you to errors in your input? Sure. We already have a lilypond server mode, which nobody wants to document or maintain. We also have http://code.google.com/p/lilypond/issues/detail?id=686 which nobody has wanted to work on for almost 4 years now. Ideas are easy. Execution is hard. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Server at Paris VIII
On Mon, May 14, 2012 at 02:25:29PM +0200, John Mandereau wrote: Hi Graham, Il giorno dom, 13/05/2012 alle 19.24 +0200, Graham Percival ha scritto: Agreed. I think the most we'd use it for would be LSR. I don't think we should give ssh logins to developers for testing patches; that should be done locally otherwise it could easily lead to major headaches [3] for whoever's handling this. [3] then again, it's not me so if you want to try it, go ahead. So, who should be initially given access to this server? Mike and you? A subset of Mike, you and me? I'd rather not touch it if possible -- I spent a moderate amount of thought+effort into the Patchy system specifically because I wanted it to be decentralized. First step is to set up patchy, which only needs your account and seems to be working fine now. Second step might be to set up some kind of server for the test-patches, if James doesn't want to do that. If James is happy with the status quo, then I guess something else next...? I'm not really certain what you want to do with that computer other than test-patches (and the server for that will likely take 5-20 hours of python hacking by you, so I'm not certain you want to work on that now). If you're interested, then try running test-patches. It won't upload anything, so don't worry about any mistakes here. Just run it, then look in the output directory and try running one of the created scripts. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Mon, May 14, 2012 at 03:38:33PM +0200, John Mandereau wrote: IIUC the From: field is not read from a config file but is hardcoded in compile_lilypond_test.py:55, can we set up to a sensible default value, or should it be made configurable? Either is fine with me. A sensible default value could be patchy %s % (os.hostname()) assuming there's a command like that in os. Can you give me your github account name, so I can add you to the lilypond-extra project so you can push directly? Also, if you'd like to rename files / classes / methods / functions a bit so they make more sense, I'm totally down with that. I know that you know more python than me, so feel free to push directly. Depending on the files you rename, the CG might need updating; see http://lilypond.org/doc/v2.15/Documentation/contributor/summary-for-experienced-developers - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc build hanging (with memory leak?)
On Mon, May 14, 2012 at 01:48:54PM +0200, Joseph Rushton Wakeling wrote: 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. Ditto. I was writing out of concern for the ease of contributing to LilyPond (more on that in a moment). I agree that it's harder to contribute than it should be. However, I am confident in stating that the summary for experienced developers is the best we can offer new (experienced) contributors given our current system and the amount of time+effort+interest the current developers have in mentoring new people. It's not ideal, but it's the best compromise I can find. If I understand correctly, Rietveld is a server-side app. My objection isn't to Rietveld per se, but to the requirement to use a custom app on my system to get my code _into_ Rietveld. This seems to be Rietveld's fault, so I'm sorry if it seemed like I was apportioning blame to the LP team. You can upload to rietveld without our custom app (but using a different one); I think you can even upload without any app at all. The reason we push our own git-cl (custom app) is that this keeps track of patches for us. Before we started using it, we lost approximately 10-20% of patches. lost as in hey guys, I sent a patch three months ago, has anybody looked at it?. Or even sadder, not having any follow-up at at all and completely losing that work. Of course, even in the three-month inquiry case, it sometimes still led to completely losing that work because git master had changed sufficiently that there were many conflicts (or else the patch just didn't make sense any more given the changed architecture). If you think that's a horrific record, then I quite agree. If you think that somebody should take responsibility for new contributors / new patches... well, that would be nice, but that's historically been lacking in lilypond. Best compromise? put the onus on patch submitters to submit with our special tool, which at least ensures that we won't lost their patch. Assuming that our current amount of interest in new patches stays constant, I am certain that turning away contributors unwilling or unable to run git-cl is doing them a favor in the long run. I was just astonished to be asked to run a tiny doc patch through a code-testing service. If you're lucky, somebody might offer to handle the red tape for you. But that would be a matter of individual luck and somebody individually offering. I'll add an extra story which may give some context to my reaction. ... That experience may have coloured my reaction when a small and easy-to-include patch, knocked off as a friendly gesture to try and make sure someone else didn't have the same scary experience I did with the new doc build system, got in response a terse instruction to submit it via a complicated and unfamiliar set of custom tools whose whole raison d'etre is to test code, not docs. It was terse because I'm on vacation but I still need to deal with lilypond crap because it's likely that nobody else will. I've spent 6 hours sightseeing in Munich, but I'm spending the rest of the day in the hotel room doing lilypond, reviewing academic conference papers, and if I'm lucky working on my thesis. Tomorrow I'll go see the science and technology museum (maybe 4 hours?), then spend the rest of the day in my hotel room again. I'm not trying to suggest that anyone is evil, bad or stupid, but it really didn't seem to me to be the best way to handle things for a case like this. Given the numerous problems that new contributors face, I believe that the most honest response is to discourage them. No, it's not easy. No, you won't get a lot of help. If that's not for you, then please wait a few months and try again -- hopefully things will be better then. This is not a pleasant policy, but I'm trying to save you guys (there have been other new contributors as well) a lot of heartache. It would be easy for me to write a feel-good email that encouraged you to keep on trying, but that would be dishonest since I know how hard it will be. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Mon, May 14, 2012 at 04:56:14PM +0200, John Mandereau wrote: Il giorno lun, 14/05/2012 alle 15.46 +0200, Graham Percival ha scritto: Either is fine with me. A sensible default value could be patchy %s % (os.hostname()) assuming there's a command like that in os. On second thought, it must be an address subscribed on both lilypond-auto and lilypond-devel, so let's make a config option for it. Well, the mail address must be subscribed, but the description doesn't need to be. I mean, it could be patchy %s %s % (os.hostname(), config.email) but then again, if somebody's putting in their config.email, they might as well give it a personal name as well. Can you give me your github account name, so I can add you to the lilypond-extra project so you can push directly? I didn't have one, I just created jmander. Thanks, added. You can either check out a new repo with the origin set up, or else change the origin manually. See the github docs for this because I don't know how to do it (although I know you do), nor do I know the correct address. Do you mean renaming files/classes/methofs in patches/, or in all directories of the repository? Just things inside patches/. If you'd like to rename directories (which could also be a good idea), I'm totally open to a discussion and I'll probably go along with whatever you suggest, but I'd still like to hear about it before you do it. :) you may even want to split the current stuff in patches/ into a shared scripts dir and a binaries (well, scripts to run) dir. I see no mention of Patchy in summary-for-experienced-developers. There's a mention of Patchy in a later chapter... I think it's in the admin chapter? I don't have the source code with me on vacation, but try git grep lilypond-patchy-staging.py and you should find the material I'm talking about. Phil Holmes wrote it, and James is either proofreading it or has edited it himself by now. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Configuring git-cl
On Tue, May 15, 2012 at 04:51:30PM +0200, Łukasz Czerwiński wrote: On 15 May 2012 16:35, Graham Percival gra...@percival-music.ca wrote: IIRC the git-cl on my github account adds a URL which allows us to search for lilypond patches (which would further reduce the chance of lost patches). IIRC this happened a few months ago, but I can't remember how to do the actual searching, nor whether this is included by default or not. As far as I understand, you mean this: http://codereview-hr.appspot.com/repos - find Lilypond and click the link search. That's what Janek has changed some time ago with my little help. Yes, exactly! However, I must admit that I'm not certain how you did this (even though I read the code!). What should Joseph answer to the git-cl questions? If you could help him write something for the CG about this, that would be awesome. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plan for discussions
On Mon, May 14, 2012 at 07:18:58PM +0200, Janek Warchoł wrote:
It's nice, but i'd go farther: what about adding an
editorial property to objects? User could mark some items as
editorial and LilyPond would take care of the rest: she would put the
editorial dynamics in brackets, make editorial slurs dashed etc. - or
hide them altogether when user asked for a urtext edition.
Out-of-the-box functionality.
Isn't that doable with a custom editorials.ly file, which would
contain a bunch of scheme and tweaks? (similar to gregorian.ly,
except with more scheme?)
I don't see this as a core lilypond thing. Rather, a user (or
group of users) would develop that functionality, then once they'd
used it for a while and it seemed stable, we'd include it in our
ly/ directory. Search the mailing list archives for ly/
directory organization for all the previous times I've tried to
get this moving.
In a way this boils down to the input syntax, but not only this. My
question is: are we more interested in supporting more notation
elements (ancient, regional, contemporary notations, special
articulations, graphic notation) or in making things work more
smoothly out-of-the-box (improving spacing - which is hard to tweak -
as well as curve shapes, etc)?
I personally am interested in helping people to do whatever they
want with lilypond. Somebody wants to work on ancient notation?
great! somebody wants to add fluffy bunnies to contemporary
notation? great! somebody wants to reduce collisions? great!
Simply creating an atmosphere where this is easy takes more
resources than we have available. As has been noted a few times,
contributing is harder than it should be, yet we still have
multiple people handling admin tasks. I think we should have more
automation, freeing up people to do more interesting/creative
tasks, allowing them to tackle the problems they want to solve.
I don't think that we're in the state where we can try central
planning for things like graphical notation. Simply coming up
with automation and policies to enable such work is already
stretching the limits of the central planning.
Have you read my articles in TLR #25 (My LilyPond experience and
LilyPond’s future)?
Sorry, not in detail.
Maybe, i'm not sure. I was thinking about our communication in
general (how to avoid conflicts and/or misunderstandings), not about a
way to formalize discussions.
IMO, a (somewhat) formalized discussion is the best way to avoid
conflicts and/or misunderstandings.
At first look this approach seems ok, but after some thought i have
serious concerns: i think this can result in syntax nice for simple
notation, but not flexible enough when things become more complex.
That's why we'd discuss the more complicated stuff later?
There are things hard to express in current syntax which i suppose
wouldn't appear in simple notation examples, so with your suggested
approach we would probably postpone them - examples :
-snip-
some of these issues could be solved by low-level changes in
architecture (at least they seem low-level changes in architecture to
me) - which means that they should be discussed early, not after the
basic changes are made.
I think you're mixing up code architecture with input syntax.
There may be some cross-over, but I'd expect such problems to
become apparent during the discussion.
I think we should take a more abstract approach, for example: what a
music expression is and what can be done with it? E.g. since
b-\staccato
means b note played staccato, should we allow
{ b b b b }-\staccato
meaning four b notes played staccato?
I'm fine with this being part of the first phase.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly
On Wed, May 16, 2012 at 09:33:09AM +0200, Martin Tarenskeen wrote: I did not see a reaction to this question, so I try again. What happened with this musicxml2ly bug ? First chords were printed below the staff, then I think it was fixed, and now the chords are below the staff again. Regression? Report bugs to the bugs mailing list, not the user or devel lists. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB make bootstrap failed at download of linux headers 2.4.34
On Wed, May 16, 2012 at 12:30:36PM +0100, Colin Hall wrote:
Running download_url
('http://mirror.anl.gov/pub/linux/kernel/v2.4/linux-2.4.34.tar.bz2',
'/home/colin/gub/downloads/linux-headers')
{}
Traceback (most recent call last):
...
Is this a surprise?
I'm slightly surprised, although no problem with GUB _really_
surprises me. Mirrors occasionally die out, but I wouldn't have
expected that one to go.
Can someone recommend a resolution?
Try finding a different mirror (use the normal kernel.net mirror
service web pages to find one), then edit
gub/specs/lilypond-headers-*.py
(possibly the wrong name)
to point to the new location, then try make bootstrap again.
If it works, then we could apply that patch to the main repo.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Successful GUB make bootstrap and bin/gub lilypond-installer
On Thu, May 17, 2012 at 08:53:32AM +0100, Colin Hall wrote: Yes. I followed this documentation: http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#lilydev http://www.philholmes.net/lilypond/LilyDev/ubuntu-LilyDev-remix-2.6.iso Great! Could I convince you to send a merge request via github for the kernel url? I can merge that immediately from the web interface; otherwise that fix will wait until I'm in Glasgow. More generally, if somebody has about 50 megabytes of online storage, it would be neat if they could prepare an unofficial release. If we hit 0 critical bugs, then I'll get a new release out, but as long as there's critical bugs remaining I'm not so urgent about making a release myself. Looking 1-2 months in the future when there's GOP and GLISS happening, it would be great if other people could handle releases. The more people who test this (to discover+fix problems like the kernel headers url), the easier it'll be to make releases. If you don't have git access then of course you can't follow the release guidelines exactly; if you do, then go ahead and push stuff to release/unstable. I'll nuke those changes when I make an official release, but there's no harm in trying out those instructions in the meantime. - Graham, on the train back from meeting Werner in Linz. Free wifi on trains?! Austria rocks! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cppcheck reports patch for 2546
On Sat, May 19, 2012 at 08:30:50AM +0200, Julien Nabet wrote: Since I don't have a Google account to sign in to http://codereview.appspot.com/, I attached the patch for 2546. Don't hesitate to tell me if it's ok or not. (I attached a link to why prefix is better). Unfortunately we do not accept patches outside of the process discussed here: http://lilypond.org/doc/v2.15/Documentation/contributor/summary-for-experienced-developers Hopefully somebody will offer to shepherd your patch through the process. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: web: news about cancelled rc (issue 6223054)
On Mon, May 21, 2012 at 06:37:59PM +, d...@gnu.org wrote: Five rounds of guesswork from several developers for a single sentence would not seem like the most efficient use of manpower for proceeding on this item. Agreed; just go ahead and push whatever you have right now. Regardless of whether it matches David's or my suggestion. But as a general note, I recommend to re-use existing news items as much as possible (i.e. copypaste to announce the latest lilypond report, only changing numbers and links. Copypaste release announcements, candidate rejections, etc. If you just copy what we currently do (or recently did), then there'll be less thinking and discussion about whether the new plan is good or not. Even more general tip about cat herding (i.e. open-source developer management): if something isn't worth discussing, then try to make sure that nobody has anything to discuss. Many lilypond policies are designed with that guideline. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to check integrity of GUB binaries
On Tue, May 22, 2012 at 03:06:56PM +0100, Colin Hall wrote: Is there some way I can check the integrity of these installers? Not a generic way. You could install the ones native to your own systems (darwin-x86 and linux-x86 inside lilydev, I guess?). If you have a web server, you could upload other binaries and ask other people to test them. It seemed to error out during or after running the tests, I need to investigate that further. perhaps you don't have a regtests/ dir with the right file(s) in it? If you're building from release/unstable then it shouldn't be any problem in that git branch. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
one week until 2.16.0
Friendly reminder -- since there are no Type-Critical issues either open or in the issues to verify, 2.15.39 is aimed to become 2.16.0 in one week. If you do not think that this is appropriate, then take appropriate action in the issue tracker. Do not tell me about it because I don't want to remember about it. On June 5 I will check the open issues and waiting-to-verify issues. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
assistants for GOP and GLISS
It would be useful if there were a few people interested in helping prepare discussions for GOP and GLISS. This would involve a number of 1-3 hour research+writing tasks. Typical examples of this work are: - read this 3000-word document and summarize the 10 bullet points that apply to us, - find a well-respected engraving of some short Bach piece freely available online, - check which major open-source projects track all copyright assignments in source code, and which ones rely on the version control for this task. These tasks are NOT going to replace discussion; they will simply be preparing+collecting background information so that we can have a more effective discussion on the general devel list. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: one week until 2.16.0
On Wed, May 30, 2012 at 06:37:48PM +0200, Jean-Charles Malahieude wrote: Le 29/05/2012 23:11, Graham Percival disait : Friendly reminder -- since there are no Type-Critical issues either open or in the issues to verify, 2.15.39 is aimed to become 2.16.0 in one week. Do you plan to build a last 2.15.40 for the po files to be in sync, or should I make a new pot and upload a new tarball (2.15.39-1) anywhere for the FTP? I will change the VERSION in release/unstable, then follow http://lilypond.org/doc/v2.15/Documentation/contributor/minor-release-checklist Those instructions currently include a po-replace, but I don't know if this means that the answer to your question is yes or no. If that plan poses some risk to translators, then add a Type-Critical issue to stop the major release. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
European lilypond meetings
I'm floating two possibilities for face-to-face lilypond meetings in the next few months. UK: I'll be in the Birmingham area on 26 June. Depending on interest and availability, there could be a short meeting that day, or a longer meeting including a stay at a BB or something like that. If there was serious interest in a longer meeting of lilypond people in the UK, we could meet somewhere else easily accessible by train (I assume that Birmingham has good links)... Northampton, Manchester...? Alternately, we could pick a different day and meet at a central rail place (Crewe would be ideal for me). Or if anybody wanted to visit Glasgow, I could supply a computer lab in addition to normal tourist stuff. GERMANY: David has offered accommodations for a few people in July, although Werner was busy during that period. If there's going to be a meeting, it would be nice if there were as many people as possible, so maybe this could happen during August? I don't know the exact dates that people were thinking, but if it's going to happen then we should start seriously planning it soon so that people can look into plane and train tickets. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB build diary
On Fri, Jun 01, 2012 at 12:56:33PM +0100, Colin Hall wrote: In the hope that it might help others, see attached diary of my work building a Lilypond release with GUB, making a trivial edit, pushing the changes to github, and submitting a pull request to Graham. Wow! I only gave it a quick skim so far, but this looks like an *incredible* resource. Beginners or near-beginners can check through your commands and compare them to what they've done, while more advanced developers can make suggestions to either your workflow or identify problems in the code or docs. I strongly suggest that everybody read this, even if you have absolutely no interest in GUB. If everybody kept records like this, we could help each other so much more. (I'll try a longer read of the diary this evening) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB build diary
On Fri, Jun 01, 2012 at 12:56:33PM +0100, Colin Hall wrote: In the hope that it might help others, see attached diary of my work building a Lilypond release with GUB, making a trivial edit, pushing the changes to github, and submitting a pull request to Graham. Ok, some more detailed reading, plus a few notes which I'm pretty certain that you already know but I want to make sure that there's no confusion about this (from you or anybody else reading it). - Installing Regtests into LilyDev and Sat Afternoon Session I believe that the perl+tar problems are fixed on my version of gub. It would be really nice if we could identify+fix any links to Jan's version, to avoid other people getting caught by this trap. - random note: a few times I've done ctrl-z to background a GUB build, then fg %1 to resume the build. It seems quite happy with that, so this is a handy way to do something else CPU-intensive for a few minutes in the middle of a four-hour GUB build. - Is this build on x86 or 64 ? I have a vague recollection of it failing for me on 64, but that may have simply been because I was using a different linux distribution at the time. - after taking a break, it would be great if you could reproduce these steps on a different (newer?) linux distribution. We don't want to be stuck on ubuntu 10.04 forever, and there's known problems with (some) later ubuntu versions. Now that you have your feet wet, you're ideally suited to working on those issues. It's true that we could always keep a VM of ubuntu 10.04 around for release purposes, but this would make it difficult for a semi-serious contributor to improve GUB. Alternately, you may want to take a look at improving GUB yourself, especially since that's how this started. :) By now you know almost as much as me about the osx part of this process, but feel free to ask more questions about that. Recall that the GUI is built from the lilypad git repo on my github account. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB build diary
On Sat, Jun 02, 2012 at 11:03:04AM +0100, Colin Hall wrote: I've done a little more work, see attached. Any suggestions on how to debug the netpbm script would be welcome. right. Oops, I'd forgotten about this until just now: http://code.google.com/p/lilypond/issues/detail?id=2184 That's pretty much all I know about this, though. The next stage in the investigation would be to remove all traces of netpbm (lock files, hashes, downloaded tarballs, build directories, etc), run make lilypond, then try to see exactly where it fails. Adding print statements to gub/specs/netpbm.py may help. Are we still in touch with the original authors of this build system? Yes and no. Most of the work was done by Jan, who is still around occasionally, but I don't think he's a regular reader of -devel any more. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB unofficial release still relevant?
On Sat, Jun 02, 2012 at 12:30:18PM +0100, Colin Hall wrote: I've just created fresh binaries with GUB. Previously [1] you suggested uploading these to create an unofficial release. Still of interest? As a general note, yes. Right at the moment with 2.16 hopefully in three days, I think it would only create confusion to advertize an unofficial release. Mind waiting a week, then having an unofficial release of 2.17.0 or .1 ? or if there's any type-Critical issue with the current release candidate, then the clock resets so we may as well have an unofficial release. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website uploads please check
On Sat, Jun 02, 2012 at 01:07:18PM +0100, Colin Hall wrote: That GUB build just finished, including the docs, and I saw a slew of rsync invocations near the end of the build: Er, did that just update the main website by any chance? no, you don't have a login. But I thought that stuff was in the lilypond-upload make rules, not the general lilypond ones. I'm pretty certain that I've built releases a few times without uploading anything. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Document and improve other simultanous music documentation. (issue 6248080)
On Sat, Jun 02, 2012 at 03:59:19PM +0200, David Kastrup wrote:
tdanielsmu...@googlemail.com writes:
On 2012/06/02 09:56:57, dak wrote:
Can you point to a coding standard or rationale for LilyPond
regarding only using @ref?
Yes.
CG 5.4.2: To create links, use @ref{} if the link is within the same
manual.
And CG 5.3.6 Cross references, which gives a list of the commands to be
used in LilyPond documents.
It does not say _not_ to use other constructs.
That was implied. Texinfo is confusing enough for most people who
begin working on the docs; just stick with @ref{}.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB unofficial release still relevant?
On Sat, Jun 02, 2012 at 04:13:12PM +0100, Colin Hall wrote: http://lilypond.org/test/v2.15.39-1/compare-v2.15.38-1/index.html Good, I'd expect them to be identical. The only difference is that the Lilypond website says: 1045 below threshold 2027 unchanged whereas my GUB output says: 44 below threshold 958 unchanged Hmm. I'm sloppy about removing old regtests tarballs, so occasionally the build creates multiple comparisons, which could easily result in 2 or 3 times the number of regtests. I wouldn't expect that to carry over to the compare-v2.15.38-1 index, but then again I wouldn't be at all surprised. That said, http://lilypond.org/test/v2.15.39-1/ only lists the results for .38, so apparently I wasn't sloppy about the last release. So I'm also in the dark about this one. But if the images look the same, then I wouldn't worry about it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB unofficial release still relevant?
On Sat, Jun 02, 2012 at 12:55:20PM +0100, Colin Hall wrote: On Sat, Jun 02, 2012 at 12:44:53PM +0100, Graham Percival wrote: On Sat, Jun 02, 2012 at 12:30:18PM +0100, Colin Hall wrote: I've just created fresh binaries with GUB. Previously [1] you suggested uploading these to create an unofficial release. Still of interest? As a general note, yes. Right at the moment with 2.16 hopefully in three days, I think it would only create confusion to advertize an unofficial release. Fine, that was the response I expected. release countdown is cancelled due to http://code.google.com/p/lilypond/issues/detail?id=2397 so if you've got some server space, an unofficial release would be great. I've just merged master into release/unstable, so a new build should be listed at 2.15.40, to avoid confusion with the existing 2.15.39. That said, it would be awesome if you renamed the binaries before uploading them to your server -- something like lilypond-2.15.39-colin-1.linux-x86.sh would be fantastic. To do this easily, I highly recommend sudo apt-get install gprename cd ~/gub/uploads/ gprename and follow the GUI. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB unofficial release still relevant?
On Sat, Jun 02, 2012 at 04:50:03PM +0100, Phil Holmes wrote: Hmm. I get no previous results to compare with. Could you let me know exactly what you've got in your gub/regtests directory, please? gperciva@gperciva-desktop:~/src/gub (master)$ pwd /home/gperciva/src/gub gperciva@gperciva-desktop:~/src/gub (master)$ ls regtests/ ignore lilypond-2.15.39-1.test-output.tar.bz2 gperciva@gperciva-desktop:~/src/gub (master)$ (when I built the 2.15.39 release, I had .38-1 in that dir and not .39-1) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB unofficial release still relevant?
On Sat, Jun 02, 2012 at 07:14:26PM +0100, Colin Hall wrote: See: http://www.charltonhall.eclipse.co.uk/ That's the space I get with my ISP account so bandwidth (cost) might be an issue. Would be nice if someone could mirror it so somewhere more robust/cheaper. Ok. Alternately, you could only put up a few binaries (say, darwin-x86, mingw, linux-x86, and linux-64). Also, advertizing it on lilypond-user as unofficial binaries will probably get you between 10 and 100 downloads in total. At 20 megs each, that's an (estimated) maximum of 2 GB bandwidth. That's probably ok for a residential ISP, but you may want to double-check. If anybody else wants to chime in and offer hosting, of course that would be quite appreciated. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB unofficial release still relevant?
On Sat, Jun 02, 2012 at 08:37:48PM +0200, David Kastrup wrote: Ok. Alternately, you could only put up a few binaries (say, darwin-x86, mingw, linux-x86, and linux-64). Also, advertizing it on lilypond-user as unofficial binaries will probably get you between 10 and 100 downloads in total. Are you also counting the web crawlers picking this up from the web presentations of the mailing lists? No, but I'm assuming that Colin would delete the unofficial binaries after a few days (a week at most) and then the web crawlers would just be pointing at empty links. If there's a serious concern about polluting web indices with invalid links, then he could rename them to be lilypond-2.15.40-unofficial-colin-1.linux-x86.sh but I think that's getting a bit over the top. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB unofficial release still relevant?
On Sat, Jun 02, 2012 at 08:33:24PM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Lilypond Dev lilypond-devel@gnu.org If anybody else wants to chime in and offer hosting, of course that would be quite appreciated. I'm personally not convinced this is worth doing. As far as a service for users, then no, it's not worth doing. But as far as a service for developer, it'll be extremely valuable. Work on GUB basically stopped a few years ago. The main point right now is just to test whether the binaries Colin's produced are valid -- particularly on OSX. I recall that he has an OSX-ppc machine; if he doesn't have an OSX-x86 machine then that's where the web server becomes useful. Once his unmodified (other than the lilypond-headers fix) GUB is known to produce good binaries, then he can start fixing other stuff. For example, IIRC all osx binaries call themselves 2.14.2-1 ? If he thinks he has a fix for it, he can whip up some new darwin binaries, upload them, and ask for testing -- without involving me (or you). If his untested patches need to wait for a new devel release, then that'll add a really annoying 2-week delay to any effort to improve the OSX releases. (or windows releases, or anything else) This is all part of my sneaky plan to diversify and broaden our developer community. Colin is now (or soon will be) able to debug+add new features to GUB without relying on me. That's a huge step forward, and both our (yours and mine) lives will be easier for it. However, if we really want to do it, I could host it off philholmes.net/lilypond, or a new domain. I can set Colin or others up with ftp access if needed. Sounds good! Again, I'm not imagining a lot of downloads. In fact, when it comes to testing experimental OSX releases, probably only the first 2 or 3 people would really matter. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB build diary
On Sat, Jun 02, 2012 at 10:14:37PM +0100, Colin Hall wrote: On Sat, Jun 02, 2012 at 07:24:20PM +0200, Jan Nieuwenhuizen wrote: Graham Percival writes: Alternately, you may want to take a look at improving GUB yourself, especially since that's how this started. :) +1 Do you mean these: http://code.google.com/p/lilypond/issues/list?can=2q=GUB Either those, or anything else that you're aware of that catches your fancy. I recall that you first became interested in GUB due to the possibility of improving the osx GUI, so I don't want to stand in your way of you working on that if you're still keen to do it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB error
On Sun, Jun 03, 2012 at 03:28:12PM +0100, Phil Holmes wrote: Tail of target/darwin-ppc/log/lilypond.log make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory `/home/gub/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master/po' make: *** [all] Error 2 Command barfed: cd /home/gub/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-master make -j16 TARGET_PYTHON=/usr/bin/env python Tail of target/darwin-ppc/log/lilypond.log huh. I tried to replicate this with a normal build from lilypond git master, but that seems to have worked. :( I'll try a GUB build late tonight, but I really don't get with the po/ stuff is doing so I'm not optimistic. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on recent Ubuntu release
On Mon, Jun 04, 2012 at 11:15:34AM +0100, Colin Hall wrote: I'm attempting GUB on 64-bit VM runing Ubuntu Server 12.04 LTS Progress so far attached. Advice welcome. sorry, one-handed typing while eating. see gub README for list of requirements. much less than lilypond build requirements. - graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on recent Ubuntu release
On Mon, Jun 04, 2012 at 12:56:58PM +0100, Colin Hall wrote: On Mon, Jun 04, 2012 at 11:15:33AM +0100, Colin Hall wrote: I'm attempting GUB on 64-bit VM runing Ubuntu Server 12.04 LTS Build failed on odcctools that sounds normal, see lilypond-devel list of previous failures. (with ubuntu 10.10 or 11.04 or 11.10?) with a claim that they require 32-bit libraries. that sounds good! well, not good, but I dont remember hearing that before. i think that's excellent debug info to get. - graham` ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new bar-lines / issue 1320
On Mon, Jun 04, 2012 at 05:01:44PM +0200, Marc Hohl wrote: Am 04.06.2012 13:21, schrieb Janek Warchoł: How about ! then? It actually has both | and . in it, and it _is_ a sentence ending punctuation. I missed something; why not keep . for the thick one? as in the current |. ? = cound be used instead of the current dashed, too. What about either [ or ] for the thick bar line? |] or |[ compared to |I I| or |! !|. I knew we'd come to this point, but besides: yes, there's many possibilities. And whatever you end up doing, we're going to change them in a few months in GLISS. My recommendation: just pick something you like and run with it. Right now this is in the sour spot of bikeshedding. We should either have a formal discussion (which waits until GLISS), or just get something done by you picking arbitrarily. I say that you should pick arbitrarily right now (or in the near future). Are there any objections/meanings about (1) moving most of the code from bar-line.cc and span-bar.cc into the scheme layer and (2) is the single glyph approach feasible? Changing . to I or whatever char is not a big problem, once the routines are settled. Yes, those are much more important things to discuss. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Document and improve other simultanous music documentation. (issue 6248080)
On Mon, Jun 04, 2012 at 11:39:05AM -0400, Kieren MacMillan wrote: Hi David (et al.), Well, we have two separate complete sentences, and joined with a comma the reader is easily confused into reading attempts as a verb, even though admittedly it would be singular and thus not a complete match to the simultaneous sections. I would say comma if the but is included, semicolon if the but is excluded. Exactly. I have no clue why (I never learned grammar), but either of those options are how I'd expect to read it. Or maybe change it to , but any attempts. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
another GUB build failure from translations
file from VC not distributed:
lilypond-2.15.40/Documentation/fr/texidocs/broken-crescendo-hairpin.ly
rm -rf /tmp/tmpEc298t
Traceback (most recent call last):
File test-lily/dist-check.py, line 137, in module
main ()
File test-lily/dist-check.py, line 132, in main
check_files (tarball, repo)
File test-lily/dist-check.py, line 117, in check_files
raise Exception ('dist error found')
Exception: dist error found
make[3]: *** [unlocked-dist-check] Error 1
make[3]: Leaving directory `/main/src/gub'
make[2]: *** [cached-dist-check] Error 2
make[2]: Leaving directory `/main/src/gub'
make[1]: *** [dist-check] Error 2
make[1]: Leaving directory `/main/src/gub'
make: *** [lilypond] Error 2
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: another GUB build failure from translations
On Tue, Jun 05, 2012 at 05:15:54PM +0200, Francisco Vila wrote: 2012/6/5 Phil Holmes m...@philholmes.net: It looks like an error in the French translation's file name - it's there as broken-crescendo-hairpin.ly whereas in es/texidocs/ (for example) it's broken-crescendo-hairpin.texidoc Ah yes, thank you, I will fix it in staging. Right? Yes. I'll try another GUB build tonight. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on recent Ubuntu release
On Tue, Jun 05, 2012 at 06:47:28PM +0100, Colin Hall wrote: I'm aware that libmpfr is a listed requirement for GUB and I have apt-get installed it. However, I see that libmpfr is also built by GUB. Not sure if it is host or cross. The history here is a bit vague, but in case you haven't seen it, http://code.google.com/p/lilypond/issues/detail?id=1827 which leads to https://github.com/janneke/gub/commit/e36a2f1b7f6770a1c0a3edea5ac17633d7f5e2bd I'm out of my depths here, but hopefully Jan could comment on tools::mpfr ? (that particular commit was removing it from cygwin rather than darwin) I'll continue with this later but pointers are welcome. No other pointers here, but I want to thank you again for your documented in-depth investigation of this issue. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
On Sat, Jun 09, 2012 at 09:19:31PM +0200, Frédéric Bron wrote: After update, it comes with g++ 4.7.0-5 and lilypon 2.15.39. Please find attached the output which looks good to me. Any idea why it does not come with a stable release (i.e. 2.14)? Because the fedora mainter(s) for lilypond think they know more about lilypond than me? *shrug* I've been fairly clear: every release says either It is strongly recommended that normal users do not use this release, and instead use the stable 2.14 version. or All users are invited to experiment with this version. Maybe I should replace the word experiment with something a bit less encouraging, or add an extra warning not to use release candidates for production work? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond miscompiled on Fedora 17
On Sat, Jun 09, 2012 at 07:55:30PM -0300, Han-Wen Nienhuys wrote: On Sat, Jun 9, 2012 at 4:58 PM, Graham Percival gra...@percival-music.ca wrote: I've been fairly clear: every release says either It is strongly recommended that normal users do not use this release, and instead use the stable 2.14 version. I don't understand the stern warnings that you accompany the devel releases with. AFAICS, they are almost all eminently usable. I don't want somebody unfamiliar with open-source software saying oh wow, 2.15.13! that's higher than 2.14.2, so I'd better try that out!, run convert-ly, then discover that there's serious bugs and be stuck having to manually un-convert-ly their scores. It's happened before. (not with 2.15.3 specifically though) One of the underlying designs of the current release process (probably changing in a few weeks) is that as soon as we have good evidence that version x.y is better for all uses than the previous stable version, we have a new stable version. In other words, an unstable version by definition does not have evidence that it's reliable enough for production use. I'm trying to protect casual users. People in the know can make up their own minds about whether they try unstable versions or not. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC comparison
On Sun, Jun 10, 2012 at 11:01:16AM +0200, David Kastrup wrote: 1.) Replace lex-bison based parser with handwritten parser in gcalctool ... I have the suspicion that the student will learn more than the project. The official response would probably be that's a feature, not a bug. Now it's not as bad as the first look: certainly more than half of the projects are not of this I could pull out my hairs variety. And those projects were likely accepted under the general GNOME umbrella rather than individually, so they don't really have more elated status than our GSoC pitch. Being part of an existing umbrella is vital. Doesn't GSoC get over a thousand applications? Think of the role that luck plays in hiring somebody for a low-level job. Imagine somebody shifting through 200 resumes, trying to find half a dozen to interview. I figure a human spent 5 minutes looking at the lilypond application before rejecting it. If I were doing it, I'd probably make my first pass rejections within 2 minutes for each application. *shrug* it's a lottery, not a competition. If you can't stand the heat... - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
giving out git push ability
Who thinks they should have git push ability? I usually tell people not to ask unless prompted, so now I'm prompting. General rule of thumb is that you should have a bunch of patches accepted, and generally be a trustworthy character. Or something like that. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[GOP2-0] why are we losing developers? a pseudo-anonymous survey
I've taken the unusual step of CCing lilypond developers directly instead of merely sending this to -devel. If you consider yourself an ex-lilypond developer, please read. LOSS OF DEVELOPERS We've lost a number of developers over the years due to policies or personalities -- some publicly, others privately. I'd like to gather a list of problematic reasons[1] why people left or lost motivation to work on lilypond. [1] good reasons are things like spending more time with family (particularly getting married or having a child), new job, or changing interests and hobbies. Problematic reasons are things like mailing list arguments, annoyance with patch-handling bureaucracy, lack of respect, etc. I'm aware of the circumstances of some of the losses, but I think it's important to gather as full a picture as we can, without compromising anybody's privacy. I'm therefore asking all ex-developers to send a pseudo-anonymous response. PSEUDO-ANONYMOUS RESPONSES I've asked Colin Hall colingh...@gmail.com to accept emails for a period of a week, from June 13 to June 20. He will: - remove the headers from the emails (mainly to remove email addresses, time/date, and server information) - assign a name to each response (developer A, developer B, etc) in random order - send the result to the public lilypond-devel mailing list. I chose to ask Colin Hall because he's a relative newcomer (and thus is not likely to be involved in any arguments which caused people to leave), but also because he's doing a fantastic job as the new Bug Meister and his GUB investigations with well-organized diaries. In some cases, readers familiar with lilypond development will be able to guess the identities of people sending responses based on the circumstances described or simply from writing style. The only response I can think of is to ask everybody to refrain from doing that, or at the very least to not make any public guesses. The discussion of these stories should always refer to the names Colin assigned them (developer A, developer B, etc). Don't go overboard when trying to make the stories anonymous, though. I mean, if somebody writes I was asked to do something by the project manager, then a day later I was asked to do it a different way, then another day later I was told not to bother, it's pretty obvious that the story is talking about me. That's fine; when discussing or referring to the stories, we will try to be willfully ignorant and pretend that we don't know who the project manager was. Because the point of this isn't to point blame at individuals; it's to see if we can make the lilypond developer community a better place for developers. DEVELOPERS ONLY For this survey, I'm asking that only lilypond developers (people with git push ability) respond. There are many problems faced by potential developers and casual contributors, and we will investigate those in a few weeks. But right now, I would like a set of pseudo-anonymous replies which we know come from existing developers. Let's fix the truly horrendous problem (experienced developers being driven away) before attempting to solve the merely terrible problem (turning away potential developers). QUESTION If you were a lilypond developer at any point in time, was your motivation to work on lilypond reduced due to problematic reasons which you are comfortable sharing with us in this pseudo-anonymous fashion? What were those reasons or the circumstances? If in doubt about what is problematic, please side with complaining rather than being silent. If you think a policy harmed your motivation, talk about it even if you think there's a good reason for the policy -- sometimes the cure is worse than the disease and we should re-evaluate those policies. If you think a specific person harmed your motivation... well, let's try not to name individuals, but if you can describe in general terms how many people were involved and how their behaviour was problematic, we could investigate the recommendations for civility and codes of conduct for open-source projects and forums. NO INVALID FEELINGS At the risk of seeming too touch-feely, I want to remind us that when writing or reading these responses, recall that there is no such thing as an invalid feeling. If somebody writes I feel that I am not respected, then that is simply a fact (unless they are willfully lying, but since the responses only come from experienced developers we can discard that possibility). The statement I _am_ not respected might be open to debate, but the statement I _feel_ that I am not respected is simply a fact. Some members of open-source communities tend to argue a great deal, but the responses to this survey are _not_ open to debate. They are simply facts, which will inform future debates about policy changes. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[GOP2-0] why are we losing developers? a pseudo-anonymous survey
I've taken the unusual step of CCing lilypond developers directly instead of merely sending this to -devel. If you consider yourself an ex-lilypond developer, please read. LOSS OF DEVELOPERS We've lost a number of developers over the years due to policies or personalities -- some publicly, others privately. I'd like to gather a list of problematic reasons[1] why people left or lost motivation to work on lilypond. [1] good reasons are things like spending more time with family (particularly getting married or having a child), new job, or changing interests and hobbies. Problematic reasons are things like mailing list arguments, annoyance with patch-handling bureaucracy, lack of respect, etc. I'm aware of the circumstances of some of the losses, but I think it's important to gather as full a picture as we can, without compromising anybody's privacy. I'm therefore asking all ex-developers to send a pseudo-anonymous response. PSEUDO-ANONYMOUS RESPONSES I've asked Colin Hall colingh...@gmail.com to accept emails for a period of a week, from June 13 to June 20. He will: - remove the headers from the emails (mainly to remove email addresses, time/date, and server information) - assign a name to each response (developer A, developer B, etc) in random order - send the result to the public lilypond-devel mailing list. I chose to ask Colin Hall because he's a relative newcomer (and thus is not likely to be involved in any arguments which caused people to leave), but also because he's doing a fantastic job as the new Bug Meister and his GUB investigations with well-organized diaries. In some cases, readers familiar with lilypond development will be able to guess the identities of people sending responses based on the circumstances described or simply from writing style. The only response I can think of is to ask everybody to refrain from doing that, or at the very least to not make any public guesses. The discussion of these stories should always refer to the names Colin assigned them (developer A, developer B, etc). Don't go overboard when trying to make the stories anonymous, though. I mean, if somebody writes I was asked to do something by the project manager, then a day later I was asked to do it a different way, then another day later I was told not to bother, it's pretty obvious that the story is talking about me. That's fine; when discussing or referring to the stories, we will try to be willfully ignorant and pretend that we don't know who the project manager was. Because the point of this isn't to point blame at individuals; it's to see if we can make the lilypond developer community a better place for developers. DEVELOPERS ONLY For this survey, I'm asking that only lilypond developers (people with git push ability) respond. There are many problems faced by potential developers and casual contributors, and we will investigate those in a few weeks. But right now, I would like a set of pseudo-anonymous replies which we know come from existing developers. Let's fix the truly horrendous problem (experienced developers being driven away) before attempting to solve the merely terrible problem (turning away potential developers). QUESTION If you were a lilypond developer at any point in time, was your motivation to work on lilypond reduced due to problematic reasons which you are comfortable sharing with us in this pseudo-anonymous fashion? What were those reasons or the circumstances? If in doubt about what is problematic, please side with complaining rather than being silent. If you think a policy harmed your motivation, talk about it even if you think there's a good reason for the policy -- sometimes the cure is worse than the disease and we should re-evaluate those policies. If you think a specific person harmed your motivation... well, let's try not to name individuals, but if you can describe in general terms how many people were involved and how their behaviour was problematic, we could investigate the recommendations for civility and codes of conduct for open-source projects and forums. NO INVALID FEELINGS At the risk of seeming too touch-feely, I want to remind us that when writing or reading these responses, recall that there is no such thing as an invalid feeling. If somebody writes I feel that I am not respected, then that is simply a fact (unless they are willfully lying, but since the responses only come from experienced developers we can discard that possibility). The statement I _am_ not respected might be open to debate, but the statement I _feel_ that I am not respected is simply a fact. Some members of open-source communities tend to argue a great deal, but the responses to this survey are _not_ open to debate. They are simply facts, which will inform future debates about policy changes. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GOP2-0] why are we losing developers? a pseudo-anonymous survey
On Sun, Jun 17, 2012 at 08:13:52PM +0100, Trevor Daniels wrote: I'm replying directly as I have nothing to say in secret. ... I suspect those that have truly left will simply not bother replying to Graham's request. Thanks for the replies, Trevor and Jonathan. Other developers: even if you have nothing to hide, please send a private message to Colin Hall instead of replying publicly. I know that there is only a small hope of contacting those who have truly left, but this anonymized survey was the best option I could think of. In order to maximize the anonymity (or at least, the appearance of pseudo-anonymity), it would be best if we didn't have any public responses at all -- if half the developers reply in public, then that narrows the possibilities for any anonymous replies. I may be going overboard with this caution, but we'll see the (anonymized) replies anyway in a few days anyway, so there's nothing much to be gained from public responses. Colin Hall: please include their responses in the anonymized list. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Multiple copies of makelsr.py
On Tue, Jun 19, 2012 at 12:52:52PM +0100, Phil Holmes wrote: find . -name makelsr.py ./scripts/auxiliar/makelsr.py ./build/input/regression/musicxml/out-test/share/lilypond/current/scripts/auxiliar/makelsr.py ./build/input/regression/lilypond-book/out-test/share/lilypond/current/scripts/auxiliar/makelsr.py ./build/input/regression/midi/out-test/share/lilypond/current/scripts/auxiliar/makelsr.py ./build/input/regression/abc2ly/out-test/share/lilypond/current/scripts/auxiliar/makelsr.py ./build/input/regression/out-test/share/lilypond/current/scripts/auxiliar/makelsr.py The extra versions are inside an .../out-test/... directory, which I believe has a symlink to the top build directory or something like that. I think that there is only a single makelsr.py file on your hard drive. Does anyone know the intention of the rsync here, and whether we really want all the /share directories and files copied to the regression test tree? I can't speak to that, sorry. I don't think that we actually want all that info copied around, or even symlinked -- if there's a need to symlink anything, it would probably be cleaner to be more specific. However, I'm not certain what the symlink (or rsync) is trying to do in the first place, so I really can't give any good recommendations about the next step. Sorry, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2-1: LilyPond is part of GNU
On Tue, Jun 19, 2012 at 03:18:04PM +0200, Janek Warchoł wrote: What happened to the formatting of this email? It looks like section numbers are in wrong places and generally i'm getting lost while reading. If you have it in a text file or something, could you send it as an attachment? Please don't top-post. As noted in the email, there is better formatting in the online version: http://lilypond.org/~graham/gop/gop_2.html Copypaste in firefox produced the previous version. Perhaps a copypaste in chrome or safari or internet explorer would produce a nicer version. Perhaps running the source (in lilypond-extra/gop/) through texi2html with different options (see the makefile in that dir) would produce nicer-formatted text. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2-1: LilyPond is part of GNU
On Tue, Jun 19, 2012 at 04:22:41PM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Here's the first main policy point in GOP 2. For those unfamiliar with GOP, here's a quick summary: make a diff between releases 11.2let’s not bother; interested parties can make a diff themselves from git. Really? git can produce diffs between developer trees, not between release tarballs. Can't it make a diff between tags? We always have tags for releases (unless that broke sometime recently). Rolling several source releases and diffing them seems like considerable work to me. While I lean towards don't bother as well, the reasoning seems shaky at best. Hmm, I may have misunderstood your comment. If my response about tags doesn't actually answer your concern, please elaborate. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2-1: LilyPond is part of GNU
On Tue, Jun 19, 2012 at 04:59:01PM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Hmm, I may have misunderstood your comment. If my response about tags doesn't actually answer your concern, please elaborate. A source tarball is not the same as a snapshot of the git tree, is it? I see your point. My understanding is that the source tarball is a snapshot of the git tree, plus auto-generated files such as INSTALL.txt which are generated solely from the snapshot of the git tree. If that understanding is correct, then I would feel comfortable arguing that a diff between git tags is sufficient to represent a diff between source tarballs. My understanding of the GNU policy is that this is a recommendation, a it would be nice for some users if you did XYZ, rather than a requirement. In the age of git and git-snapshot-tarballs and the like, I think this recommendation is less valuable than it was ten years ago. However, I could be mistaken. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2-1: LilyPond is part of GNU
On Tue, Jun 19, 2012 at 05:18:57PM +0200, David Kastrup wrote: So there was considerable and non-trivial difference between a vcs diff and a release tarball diff. And the instructions reflect that. I am not really all too sure how to apply this to our situation. At present, I think most people would not really be interested in a separately downloadable diff anyway. Yes. Further discussions on the GNU maintainers list (since yesterday) shows that there's general contentment with using the primary source (i.e. git) for the authors list, and I'm confident that this applies to the recommendation of providing diffs as well. So I'm going to cross this off from the list of things to worry about. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2-1: LilyPond is part of GNU
On Tue, Jun 19, 2012 at 03:51:21PM +0100, Phil Holmes wrote: My web space runs windows IIS. We have the .iso and occasional tools (e.g. the regtest rater) running on this. Do you think this is a problem? Ouch, I'd forgotten about the regtest rater. That's C#, right? or is it .NET ? I don't actually know what the difference is. Do you have any idea if it will work under dotGNU or Mono? I'm not too concerned about the .iso; if necessary we can find other places to host it. But it would be an absolute travesty if the something happened to the regtest rater. I'm making enquiries on the GNU side. do not recommend any non-Free programs We have a list of non-free ones on the easier editing page - e.g. Noteworthy and my converter. However, it seems daft to me to remove these. I would think for the long list we could disclaim with we're not recommending these, but noting that they exist. Thanks, that seems reasonable. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Survey response completed [GOP2-0] Why are we losing developers?
On Fri, Jun 22, 2012 at 11:09:14AM +0100, Colin Hall wrote: I have posted all the responses to the survey. Thanks so much for your help, Colin! I suggest that we spend a few days to think about the responses and how we view the project, then start discussing them on Monday. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Treat accidentals parentheses as cautionary (issue 6310065)
On Fri, Jun 22, 2012 at 08:58:13AM +, julien.ri...@gmail.com wrote: I just did a git am using his patch, but I'll amend the commit before pushing. Do we need some license statement from Rodolfo? No; lilypond is not FSF-copyright-assigned, so nothing is needed. But thanks for checking! - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release.
On Mon, Jun 25, 2012 at 11:07:38PM +0200, David Kastrup wrote: The release policies demand 2 weeks without critical regression after a development release. So far, we have rarely lasted a single week. The policies are slated for rediscussion at the end of summer. By that time, we'll not be hitting the freezes for the fall releases of the distributions. if by the end of summer you mean today? 201-06-27 GOP2-2 - Stable releases and roadmap (radical change) http://lilypond.org/~graham/gop/ ok, admittedly I typo'd the 2012 part of it, and remember that the policy question is -1 day from the wednesday (i.e. on Tuesday the 26th). This has been scheduled for a few weeks; check the git log for lilypond-extra if you want. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR updates and translations
On Mon, Jun 25, 2012 at 12:31:45PM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Thursday, June 21, 2012 7:47 PM Subject: Re: LSR updates and translations Minor note: IIRC such a directory already exists, so you may need to give it a different name, or play some other games with the build system. Similarly, while working on this new system, it might be easier to give it a different name to avoid conflicts with the existing Documentation/snippets/. I mean, sure, ideally you could change everything at once and have no oddities with the old snippets and the new snippets, but I would personally be quite leery of attempting such a thing. Yes, that directory exists. Good point. perhaps the best name would be /build/Documentation/snippet-src? If you're going to rename stuff, I strongly suggest a bigger rename or you're asking for trouble. I suggest Documentation/lsr/ ? and Documentation/lsr/new/ ? and then the corresponding /build/ dirs will be created. How do you deal with new snippets (which cannot run on the current LSR), and most awkwardly, *updated* snippets (which the LSR version works fine in the previous stable version, but the syntax has changed in a non-convert-ly-able manner and requires a manually-updated version) ? The same way - with a snippets/new list, where these over-write the snippets from the tarball. We may need to consider some other name changes here. Clearly the simplest way to create an updated git/Documentation/snippets directory is a simple delete of the old one, and a copy of the docs snippet tarball over to git/Documentation/snippets. However, this would also wipe out git/Documentation/snippets/new, which would be a Bad Thing. What about an empty directory called git/Documentation/snippets, one with updated non-LSR-runnable snippets called git/Documentation/snippets/new, and one with the snippets from the tarball in called git/Documentation/snippet-src? Sorry, I didn't follow that. My vague sense from the emails is that John and Julien are interested in helping to do this work, but nobody feels quite certain about exactly what's being proposed. Could you write a new email (possibly with copious copypastes) with the latest proposal, using new directory names for the new version (to lessen confusion) ? We don't need to go over the motivation for this work; just the actual details of the work, with whatever tweaks you think are good based on the past week of emails. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release.
On Tue, Jun 26, 2012 at 09:01:20AM +0200, Jan Nieuwenhuizen wrote: Graham Percival writes: 201-06-27 GOP2-2 - Stable releases and roadmap (radical change) http://lilypond.org/~graham/gop/ [empty document] That's a pretty radical change, already ;-) My parents were visiting for the past week. I have a six-hour train ride back to Glasgow starting at 11:47. I said I'd introduce the question today, and I will do that. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release.
On Tue, Jun 26, 2012 at 07:33:12AM +0200, David Kastrup wrote: My proposal was just about a release addressing bit rot, namely just making sure that the equivalent of the existing release 2.14.2 can be compiled (with no regressions due to the recompilation) on current systems that insist on not using precompiled binaries from us (which is quite sensible for distributing GPLed software). Assuming that this is a 10-minute job, put stuff in the stable/2.14 git branch, just in case somebody grabs the source from git tarball. Once that's done, somebody might take a look at running GUB, then at least we'd be able to make some intelligent guesses about what's involved there. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release.
On Mon, Jun 25, 2012 at 11:07:38PM +0200, David Kastrup wrote: The release blocking issues could be fixed with minor reverts. The usual release blockers are not revertible. Even if the current set is get cleared out, history tells us that the time window of two weeks after unstable release is unlikely to finish before the next detected regression. Well, we had at least a week when the only release-critical bug was the po-replace translation thing. It's a bit silly that we couldn't have a release due to a 5-line texinfo documentation thing, and in retrospect I should have done a hostile revert (especially since the commit in question didn't go through any review or countdown). But since the developer survey was coming up, I didn't want to open any new wounds. Also, I was more sick of arguments than normal, so again I didn't want to start a new fight. In hindsight I should have reverted it. And if there's no clear offer to fix it before tomorrow, I'll revert it anyway. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release.
On Tue, Jun 26, 2012 at 09:30:12AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Assuming that this is a 10-minute job, put stuff in the stable/2.14 git branch, just in case somebody grabs the source from git tarball. It's more than 10 minutes since I have to through hide-and-seek-and-recompile-and-check a few times. But I don't think it will take me longer than a few hours. Your computer really isn't suited to this task. I suggest that you wait a few days and hope that somebody else will volunteer -- possibly in conjunction with you? i.e. you could prepare a git branch (maybe dev/2.14-proposed or something like that), then the other person could try to compile it, then send you the build failure and you can go huntcherry-pick the relevant commit. There's no rush for this at all, so it doesn't matter if it takes two weeks with a day of lag each way. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR update - a further question
On Tue, Jun 26, 2012 at 11:59:14AM +0200, John Mandereau wrote: Le mardi 26 juin 2012 à 10:17 +0100, Phil Holmes a écrit : 2) Use a script to update $LILYPOND_GIT/Documentation/snippets. This deletes all the old snippets except /new; reads all the snippets in the tarball; adds the correct lsrtags and writes the resulting output to $LILYPOND_GIT/Documentation/snippets. I'm happier with 2), this is what makelsr.py already does among other things. +1 - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Importing, updating, translating and building Lilypond snippets
On Tue, Jun 26, 2012 at 01:39:19PM +0100, Phil Holmes wrote: A script is run (makesnippets.py?) which iterates over all the directories in the extracted tarball and all the files in each directory. It adds a line: lsrtags = dir-1, dir-2 to each snippet, where dir-n is the directory name in which the snippet is found in the tarball. why? if we ever add a new tag, some of the numbers will be changed for no reason. Why not keep the named tags in those .ly files? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Importing, updating, translating and building Lilypond snippets
On Tue, Jun 26, 2012 at 02:21:43PM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org On Tue, Jun 26, 2012 at 01:39:19PM +0100, Phil Holmes wrote: lsrtags = dir-1, dir-2 to each snippet, where dir-n is the directory name in which the snippet is found in the tarball. why? if we ever add a new tag, some of the numbers will be changed for no reason. Why not keep the named tags in those .ly files? That's what I mean. I was using 'dir-1' as a shorthand for the actual directory names. Sorry. I didn't read carefully enough, and was expecting something like lsrtags = foo, bar rather than the numbers (that made me think of things like \omega_n to represent the freqencies of modes of vibration, where n is clearly the only part that changes). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP2: 0 - why are we losing developers? (discuss responses)
*** HTML-formatted version: lilypond.org/~graham/gop/gop_1.html *** Summary We’re not in terrible shape, but we’re not in good shape either. *** Details Survey sent: http://lists.gnu.org/archive/html/lilypond-devel/2012-06/msg00192.html There were 11 responses: devA devB devC devD devE devF devG devH devJ devK devL (direct links in html version) *** Summarize of those emails Here is a rough summary of the 11 responses. 4 developers (devA devE, devJ, devK) did not report any “problematic” reasons. Of the remaining 7 developers, the reported problems are: Patch-handling (git branch, countdown, staging, etc)devB devC, devF, devH, devL Mailing lists arguments devB, devC, devG maintenance procrastination; things not getting donedevC devH lack of people with specific responsibilities (particularly mentors)devC, devD lack continuous integration environment and really automated testing devB no feeling of “teamwork”devC too long / too much effort to produce stable releases devC number of open issues (overwhelming, demoralizing) devC difficult to contribute with windows and a slow computer (lilydev is not suitable)devG feeling that other people could complete a task much quicker devH time spent reading+writing emails devH Reviews (lack of quantity, to much nitpicking of words) devH lack of overall vision or roadmap devH *** Initial thoughts about the response Obvious “policy” problems to discuss in the coming weeks: patch handling, stable releases, roadmap, better testing. Mailing list arguments are a trickier issue. It’s clearly a big problem, but this isn’t something we can fix by waving a change of policy. I’ll schedule a time to discuss it. We need to do something about this, although at the moment I have no immediate suggestions. Lack of people with responsibilities, mentors, lack of reviews type of reviews, things not getting done, number of open issues: I don’t see many “policy” that can help with this (other than generally encouraging people to spend more time and/or eliminating things which drive people away). It’s certainly to note that these are problems, though. The best I can think of is to clarify who is currently responsible for what, and make the vacancies more apparent. Again, I’ll schedule a time to discuss these. There are a few problems that I can’t see any real “project” solution to: difficult to contribute with windows, feeling that other people could finish tasks faster, time spent reading+writing email. I suggest that we simply acknowledge that those are problems, but focus discussion on other issues. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Meeting 2nd half of August! (was: GOP2: 0 - why are we losing developers? (discuss responses))
On Tue, Jun 26, 2012 at 05:44:19PM +0100, Colin Hall wrote: On Tue, Jun 26, 2012 at 06:26:34PM +0200, David Kastrup wrote: Decent communication in electronic media is one of the things I am spectacularly bad at. One thing that has turned out to be effective at times is meeting people in person. I think this is an excellent idea. Anything that gets us away from typing at each other and towards human contact is a good thing. A less expensive option could be skype chats (or a different program if people wanted an open-source one). These could even become regular events, such as every Wed at 10:00 UST and Thurs at 23:00 UST. (picking dates/times randomly) I'm not suggesting video, since even my university internet connection doesn't handle video chats well, but voice could work out. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release.
On Tue, Jun 26, 2012 at 07:19:28PM +0200, Jean-Charles Malahieude wrote: Le 26/06/2012 09:24, Graham Percival disait : Well, we had at least a week when the only release-critical bug was the po-replace translation thing. It's a bit silly that we couldn't have a release due to a 5-line texinfo documentation thing, and in retrospect I should have done a hostile revert (especially since the commit in question didn't go through any review or countdown). Issue 2524: Patch: CG: add updating of lilypond.pot in the release process Comment 7 by lily...@orange.fr, May 14, 2012 Pushed as f7d264fa89c39f8d86e9ba5eb991ee904ce3d0be Please, Graham, read before writing nonsense! or express it in another way. Comment 12: release-critical identified. (Graham) Comment 13: ok, revert it. (you) % I revert it Comment 16: fixes pushed to staging (John) Where was the review between comment 13 and 16? if there had been a review, I could have pointed out that the fix had essentially the same problem as the patch in comment 7. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Meeting 2nd half of August! (was: GOP2: 0 - why are we losing developers? (discuss responses))
On Tue, Jun 26, 2012 at 06:26:34PM +0200, David Kastrup wrote: So the core data would be Dortmund Germany (about 10 miles from there) and the proposal for a date would Friday August 17th to Tuesday August 21st, or one week later. Any idea about the connectivity with nearby airports? Flying to Dortmund seems to involve three flights over 2000 euro, whereas flying to Dusseldorf is 250 euro. It's probably safe to assume that Germany has good railways for Dusseldorf to Dortmund? (or maybe Essen or Cologne?) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP2: 2 - Stable releases and roadmap (radical change)
Not quite up to the ideal standard of GOP proposals, but there's a lot of interest and this should be enough to see what way the wind is blowing. html-formatted version: http://lilypond.org/~graham/gop/gop_3.html *** Summary Let’s drop the “any unintended change” thing, and go totally with the regression tests. Tests pass? We can make a stable release. Also, let’s have an official roadmap. *** Motivation There seems to be widespread frustration with the current system. At the moment, any “unintended change” blocks a release (plus a few extra conditions), so we’re at the mercy of all sorts of behaviour that isn’t covered by the regtests. This makes it hard to plan ahead for everybody: developers wanting to work on large features or refactoring, users, linux distribution packagers, etc. *** Details: Critical issues A type-Critical issue will block a stable release, but the definition is: -a reproducible failure to build either make or make doc, from an empty build tree, in a first run, if configure does not report any errors. -anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available, LilyDev being unable to compile git master, inaccurate instructions in the Contributor’s Guide 2 Quick start). To limit this scope of this point, we will assume that the contributor is using the latest LilyDev and has read the relevant part(s) of the Contributor’s Guide. Problems in other chapters of the CG are not sufficient to qualify as Type-Critical. -any regression test which fails to compile or shows incorrect output. The only change is to the third point, namely the “regression test failure” as opposed to “any unintentional change”. *** Details: Regtests The current regtests don’t cover enough – that’s why we keep on finding new regression-Critical issues. I think it’s worth expanding the regtests and splitting them into multiple categories. These names don’t (deliberately) match any specific testing methodology. If they do, then it’s probably a mistake and we should rename these. Crash: we don’t care about the output of these; we just want to make sure that lilypond doesn’t crash with this input. Tiny: these files would test individual features, such as printing accidentals or slurs, with a minimum of shared features. Integration: these are constructed examples which combine multiple features together. Pieces: musically-interesting fragments of music, such as a few systems from a Bach sonata or Debussy piano work. Syntax: short fragments of music for which the .ly files are “frozen” – we never run convert-ly on these files until LilyPond 4.0. (see below, “roadmap”) I figure that we’ll double the total number of regtests. There’s probably some old ones that can be eliminated (or combined with newer ones), but we’ll be adding a lot more. *** Programming regtests To avoid slowing down programming to a crawl, I figure that we’ll identify some subset of these regtests and have a separate make regtests-quick command which only evaluates that subset. As a rule of thumb, I’d say that the regtests-quick target should take as long as a make from scratch. I’m sympathetic to developers with limited computing resources, but I think it’s reasonable to ask everybody submitting programming patches to “double” the time it takes to test their patch (since obviously everybody would run make before submitting anything). The patchy test-patches will still run the full regtest checks. *** When breakage occurs There will of course be functionality which breaks. When that happens, we file a normal bug. A new regtest can only be added for that bug when it is fixed – we won’t add the regtest first, then try to fix it. In other words, git master should always pass all regtests. If it doesn’t, then reverting should be the first option. *** Roadmap With this change, we would no longer be committed to the same kind of stability that we were before. As such, I think it’s worth bumping the version up to 3.0. The 3.x series will consist of a series of random breakage from functionality not covered under the existing regtests and from manual .ly changes required by GLISS. This is intentional – or rather, we don’t intend to break stuff, but the policy accepts that this will happen. Somebody may offer to maintain the 2.x series to cater to users who want additional stability. Over the next 3 months or so, we’ll discuss a number of syntax changes in GLISS. Then discussion will cease until all the changes have been implemented. We’ll then have release 3.2, which will almost certainly require manual changes to all .ly files. We’ll then have another few months of GLISS discussions, then a pause for implementions, then 3.4. Repeat as necessary. LilyPond 4.0 will mark the ending of GLISS, and by that point we should have much improved regtest coverage. We can’t really plan too much for this, since it’s likely two years
Re: GOP2: 2 - Stable releases and roadmap (radical change)
On Wed, Jun 27, 2012 at 05:33:47AM +, Keith OHara wrote: Graham Percival graham at percival-music.ca writes: -any regression test which fails to compile or shows incorrect output. For any changed test then, it is probably worth reading the header, to see if a subtle change that looks harmless happens to be the point of the test (and would presumably cause other trouble). Hmm. It could be necessary to add either the texidoc to the regtest comparison page, or add markup to the score itself to highlight any subtle points which are vital. The incorrect output should only count where the previous stable release gave correct output. Lots of tests show behavior that some people think is wrong (‘accidental-ledger.ly’ ‘ambitus.ly’) or that looks bad because it is a a stress test (‘break.ly’ ‘prefatory- separation.ly’ ‘spacing-strict-spacing-grace.ly’). Yes; there is a hidden assumption that the existing regtests have been exhaustively checked and we agree that they pass (again, possibly only after making a note in the texidoc that the output may look too squished or something). I'll make that assumption explicit. *** Details: Regtests The current regtests don’t cover enough – that’s why we keep on finding new regression-Critical issues. I think it’s worth expanding the regtests and splitting them into multiple categories. This cannot be done quickly. Yes; I should have noted that it will likely take 100+ hours. Adding a few pieces of music in various styles might help, but I remember from my regression this cycle that my patch worked fine on score and parts of a full symphony, but then version 2.15.37 failed spectacularly on two pages of guitar music. Yes. Under this proposal, version 2.15.37 could have became 2.16.0, even with that spectacular failure known, because that particular edge case was not checked in the regtests. The fix would not occur until 2.16.1 or later -- possibly years later. Tiny: these files would test individual features, such as printing accidentals or slurs, with a minimum of shared features. As a goal, I suggest Targeted instead of Tiny -- testing performance in one narrow area, but thoroughly. More often than not, after I fix a bug, I find a regtest that should have caught it, and expand that test rather than add a new one. good idea! I've modified the name. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Meeting 2nd half of August!
On Tue, Jun 26, 2012 at 11:13:21PM +0200, David Kastrup wrote: Düsseldorf -- Dortmund -- 45 minutes hourly Sounds good. Ok, I'm in as long as we have at least 3 developers other than myself. So far there's David and Werner. Mike, are you completely unavailable for that period? I recall that David suggested two weekends; you're away for both? That's a shame. What are the details of accommodation and food (prices and availability)? are there nearby restaurants we'd be going to, or a large kitchen, or...? I don't know exactly what a sort-of commune in a rural region means. :) If there's a large kitchen with shared meals, then I will cover all non-alcohol grocery bills. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
