Re: improving our contributing tools and workflow
Jan Nieuwenhuizen jann...@gnu.org writes: Graham Percival writes: On Thu, Sep 26, 2013 at 02:05:44PM +0200, Jan Nieuwenhuizen wrote: - plain email-based patch submission using a benevolent dictator, ie, use git the way it was designed and is still used by the creators (linux, git). Are you volunteering to be that benevolent dictator? I'm sorry, not at this time. Spend, say, 15 hours a week reviewing and approving patches? I have no quarrel if you want to do that. I do not share this assumption that this setup would cost time. What I am suggesting is that this may help David and core developers if he would take this up. I think that the continued success of Linux is for a great part a result of this development setup. The dictator works closely only with one to three core developers hardly bothers with the rest. Well, you have obviously adjusted the numbers to fit LilyPond better than Linux, but that setup still calls for one to three core developers to filter every submission. Now I readily agree that my gut feeling about a patch definitely increases when I've seen Keith make it go through the works in a review. But there is just so much Keith to go around, and then it is not like he does not work on patches himself. Another problem with the dictator role is that he has the managerial, technical and human competence to deal with direct or at least indirect submissions in _all_ areas of the code. For me, much of the code base is inherited. I'm not actually qualified to give a blessing to code. Now if you take a look at the Linux processes, you'll find that Linus at least is _trusted_ to give an opinion for anything (and of course, since the Linux master is his personal repository where nobody else may write, he _is_ the ultimate arbiter). He delegates a lot, sure, but when this delegation of trust breaks his expectations, the fallout can easily make a developer go away. We don't have a lot of developers to start with. When Linus worked with a set of developers as small as the currently active LilyPond core team, he was much more friendly, forthcoming, open and helpful. His leadership style developed as a consequence of things going wrong and right, and adapted as the size of the project grew. Now look what a personality I'm starting with... He does invest some time in getting those core developers to create the kind of patches and code that he likes, so that after some time he can pull their patches with hardly looking at them at all. And that as a network all the way down. That ensures a very high level of quality, while freeing up the people at the core. All the way down is a small way for LilyPond. And we don't have that many people to free at the core. The whole system is set up to minimize the demands on main developers. Any solution which shifts the burden away from contributors and onto main developers is IMO bad for LilyPond. Of course. One fundamental difference is the kind of developer and/or helper the respective projects tend to attract. LilyPond is conceptually not that much simpler than an operating system kernel, but it's sexy to quite a different set of people. And making it usable requires different focus. Linux does not have anything remotely close to our documentation system, let alone translations, and it does not have a frontend and extension language. Basically, it's backend all around. Now we actually could use a _team_ of backend hackers which don't work on improving _what_ the backend does (that's what Gould and friends prescribe), but how one tells it how to do that, and how it picks the path from there. Because we have reached a state of fragile equilibrium where any additions require lots of care in order not to break conceptually unrelated stuff. That leads to half-done solutions like the skyline stuff: we have the ability to place staves closer now, and as a result, we now need _more_ pages for any given score. That's because the ability to place things closer necessitates more padding, and our page breaker only see the additional padding but not the ability to place staves closer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Microtonality (was: improving our contributing tools and workflow)
Hans Aberg haber...@telia.com writes: On 26 Sep 2013, at 17:16, Phil Holmes m...@philholmes.net wrote: The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think it's waiting for someone to propose how it could be represented in LilyPond. For one microtonal accidental, one needs, in addition to the minor/major seconds m and M, a neutral second n. For a pitch x = r*m + s*M + t*n, compute its degree deg(x) := r + s + t, which is its staff position, and subtract the staff pitch. There remains a new pitch, which I also call x, but now with r + s + t = 0. As sharps/flats alter with a multiple of r - s, reduce using them so that only one of r, s is non-zero. Assume first that t = 1, i.e., one n. Then it must be either n - M or n - m. We have six microtonal symbols, sharp/natural/flat with up/down arrows, but it will, as we shall see, suffice with four. One way to make a choice is to conceptualize n as below or above (m + M)/2: if it is a small or large neutral. This choice is purely formal at this point, but will be of importance when plugging in values. [...] If the absolute value |t| of t is larger than 1, then one needs as many arrows as |t|: up if t is positive, and down if t is negative. Two symbols where not used: sharp with up arrow and flat with down arrow. But they conceptually fall without the region of raising a sharp M - m or lowering with a flat -(M - m), and can in fact be reduced using a natural with up/down arrow plus a sharp/flat. So here, one would need notation simplification algorithm. Well, today's xkcd, at the surface more being about LilyPond's choice of extension language, still seems somewhat on-topic here: URL:http://xkcd.com/1270/ (mark the mouse-over text) Now I appreciate that you are no longer expounding on Abelian groups here, but this still is not a text you'll find in a musician's handbook (not even if he's called Arnold). If you are interested in getting your ideas conceptualized in a manner that will make both musicians and LilyPond programmers understand them to a degree where they can work with them and actually want to do so, you need to diverge further from the abstract. I remember that my initial (and it turns out terminal) reaction to your initial group theoretic treatise a year ago or two was I'll read this some other time. If you take into account that I'm the sort of guy who chose to do a treatise on number-theoretic transforms for convolutions as an undergraduate term paper in an engineering course, that should raise a lot of warning flags. So how do we stop this from putting a terminal halt on the discussion this time? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Graham Percival writes: On Thu, Sep 26, 2013 at 02:05:44PM +0200, Jan Nieuwenhuizen wrote: - plain email-based patch submission using a benevolent dictator, ie, use git the way it was designed and is still used by the creators (linux, git). Are you volunteering to be that benevolent dictator? I'm sorry, not at this time. Spend, say, 15 hours a week reviewing and approving patches? I have no quarrel if you want to do that. I do not share this assumption that this setup would cost time. What I am suggesting is that this may help David and core developers if he would take this up. I think that the continued success of Linux is for a great part a result of this development setup. The dictator works closely only with one to three core developers hardly bothers with the rest. He does invest some time in getting those core developers to create the kind of patches and code that he likes, so that after some time he can pull their patches with hardly looking at them at all. And that as a network all the way down. That ensures a very high level of quality, while freeing up the people at the core. The whole system is set up to minimize the demands on main developers. Any solution which shifts the burden away from contributors and onto main developers is IMO bad for LilyPond. Of course. Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
On 26/09/13 18:38, David Kastrup wrote: You commented on the issue where this patch originated as late as July: URL:http://code.google.com/p/lilypond/issues/detail?id=1278#c7. So it's hard to argue that it was not discoverable to you. This July I got an email update from the issue, and responded. The creation of the issue tracker was pointed out to you in a direct reply by Valentin in URL:http://lists.gnu.org/archive/html/bug-lilypond/2010-09/msg00424.html. I was never unaware of the _issue_, it's the code review that I was not involved in (and did not receive email updates from). Most likely it's because the issue update with the link to the code review arrived on 30 December 2010, with subsequent updates going up to February 21, which was a period when I was completely snowed under with work issues. By the time I caught up with progress, the code review was long over and the patch had been abandoned. The discussion thread containing this pointer consists of four mails. Three of those mails were written by yourself, only the final reply with the pointer to the tracker issue was written by Valentin. I doubt that using a different tool would have changed your perception of never having been invited to take part in that review. There is a difference between getting auto updates on an issue and getting an invitation to participate or give feedback. When I've submitted code to a project that attempts to resolve a user's issue, I've usually written to them directly asking for their input and involvement. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 26/09/13 18:38, David Kastrup wrote: You commented on the issue where this patch originated as late as July: URL:http://code.google.com/p/lilypond/issues/detail?id=1278#c7. So it's hard to argue that it was not discoverable to you. This July I got an email update from the issue, and responded. The creation of the issue tracker was pointed out to you in a direct reply by Valentin in URL:http://lists.gnu.org/archive/html/bug-lilypond/2010-09/msg00424.html. I was never unaware of the _issue_, it's the code review that I was not involved in (and did not receive email updates from). Since the code review was announced via the issue tracker just like the Email update you responded to, you would have received it just the same, or the announcement would already have been part of the issue at the time you chose to subscribe to issue notifications. So it seems somewhat specious to place the blame on the involved tools or developers and complain that you were not invited to participate in the review. There is a difference between getting auto updates on an issue and getting an invitation to participate or give feedback. When I've submitted code to a project that attempts to resolve a user's issue, I've usually written to them directly asking for their input and involvement. Now that we cleared up that nothing but personal service is sufficient for soliciting your participation in issues of interest to you, can you explain why we were having this discussion about improving contributing tools and workflow in the first place? How is this reconcilable with your statement that you would not want to use any process that would require manual labor from anybody else? It's probably rather obvious, but I really have a hard time deriving enjoyment and motivation from the contribution you are making to LilyPond in this discussion. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 27/09/13 03:44, Graham Percival wrote: On Thu, Sep 26, 2013 at 03:12:27PM +0200, Joseph Rushton Wakeling wrote: This risks becoming another corrosive discussion, Then WTF are you starting it? Because I had hoped that what I said was sufficiently qualified not to create bad feeling. Obviously I was wrong. I am happy to answer any of the questions you've asked, but I will not do so on-list, because it's obvious this will just perpetuate an unnecessarily divisive discussion. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
improving our contributing tools and workflow
Hi all, after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. In a truly Grahamic spirit, i'm going to focus on this issue and not participate in anything else on the mailing list until we're done (with the exception of Tie Crusade which i hope to resurrect). best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: LilyPond Development Team lilypond-devel@gnu.org; David Kastrup d...@gnu.org; Joseph Wakeling joseph.wakel...@webdrake.net; Phil Holmes m...@philholmes.net; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 10:48 AM Subject: improving our contributing tools and workflow Hi all, after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. In a truly Grahamic spirit, i'm going to focus on this issue and not participate in anything else on the mailing list until we're done (with the exception of Tie Crusade which i hope to resurrect). Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
2013/9/26 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł janek.lilyp...@gmail.com after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. In a truly Grahamic spirit, i'm going to focus on this issue and not participate in anything else on the mailing list until we're done (with the exception of Tie Crusade which i hope to resurrect). Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: LilyPond Development Team lilypond-devel@gnu.org; David Kastrup d...@gnu.org; Joseph Wakeling joseph.wakel...@webdrake.net; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 11:13 AM Subject: Re: improving our contributing tools and workflow Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek I don't see why you would get that impression. I will participate as usual, although noting that my summer vacation ends this weekend. I was simply reiterating something that Graham said to me on a number of occasions - don't assume that the work you do will be accepted - it's always possible that anything done on a collaborative project won't be. Patches are criticised, changed and occasionally junked, and the same can apply to proposals for changes in tools and processes - so don't become too committed and expend more work than you can afford to lose. Ever. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Janek Warchoł janek.lilyp...@gmail.com writes: 2013/9/26 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł In a truly Grahamic spirit, i'm going to focus on this issue and not participate in anything else on the mailing list until we're done (with the exception of Tie Crusade which i hope to resurrect). Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. There is a joke about an experimental physicist approaching the college dean for funding a collider. The dean is annoyed: Why can't you be like the mathematicians? They just need pencils, paper, and a wastebasket and will work for years. And the philosophers don't even need a wastebasket... Joke aside: if you are going to do serious programming or infrastructure work, your most important tool _will_ be the wastebasket. You can't make decisions without evaluating things, and evaluating things does not even mean that the work will lead to a change from the current state of affairs. It may make you realize that minor changes will already address some problems, for example. If that sounds very discouraging to you, don't study mathematics. And actually, I'd not recommend studying philosophy either, if just for the sake of philosophy. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 12:26, David Kastrup wrote: The dean is annoyed: Why can't you be like the mathematicians? They just need pencils, paper, and a wastebasket and will work for years. And the philosophers don't even need a wastebasket... Not any more, either for mathematicians or philosophers ... :-) You can't make decisions without evaluating things, and evaluating things does not even mean that the work will lead to a change from the current state of affairs. It may make you realize that minor changes will already address some problems, for example. Quite, but one of the problems we have right now is that it's not clear what the broad requirements are. For example -- we know that GitHub is out because of its proprietary nature. That means that no one is going to waste time setting up a trial system using GitHub. There are surely other things that can be clarified now so as to not evaluate systems that are going to be rejected out of hand. For example -- is it essential that any solution proposed work well with Google Code issues? Or will consideration be given to a solution that involves an alternative issue tracker? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net To: David Kastrup d...@gnu.org; Janek Warchoł janek.lilyp...@gmail.com Cc: Phil Holmes m...@philholmes.net; LilyPond Development Team lilypond-devel@gnu.org; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 12:51 PM Subject: Re: improving our contributing tools and workflow On 26/09/13 12:26, David Kastrup wrote: The dean is annoyed: Why can't you be like the mathematicians? They just need pencils, paper, and a wastebasket and will work for years. And the philosophers don't even need a wastebasket... Not any more, either for mathematicians or philosophers ... :-) You can't make decisions without evaluating things, and evaluating things does not even mean that the work will lead to a change from the current state of affairs. It may make you realize that minor changes will already address some problems, for example. Quite, but one of the problems we have right now is that it's not clear what the broad requirements are. For example -- we know that GitHub is out because of its proprietary nature. That means that no one is going to waste time setting up a trial system using GitHub. There are surely other things that can be clarified now so as to not evaluate systems that are going to be rejected out of hand. For example -- is it essential that any solution proposed work well with Google Code issues? Or will consideration be given to a solution that involves an alternative issue tracker? As far as I'm concerned, Google Code could be changed. I find its restriction on attachments annoying. However, a replacement would have to be able to import _all_ the issues lodged there with all their detail and attachments, and provide similar facilities. If it made other stuff easier, great. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Janek Warchoł writes: Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? You may want to study - plain email-based patch submission using a benevolent dictator, ie, use git the way it was designed and is still used by the creators (linux, git). Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Hi, to make things clear: i do not intend to attack anyone personally, or imply that anyone has bad will or malicious intentions. I only want to explain how the situation looks like from my point of view. 2013/9/26 Phil Holmes m...@philholmes.net: Janek wrote: 2013/9/26 Phil Holmes m...@philholmes.net: Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek I don't see why you would get that impression. Because your message sounds pessimistic. It sounds like you consider it likely that my attempt to do something good will fail. It sounds like you are not concerned with ensuring that this initiative suceeds and brings benefit to all, but rather you are thinking about the damage and problems it can bring. Thinking about problems isn't bad in itself, but if there's more focus on problems rather than benefits, things get discouraging. Actually, it seems to me that this happens really often in lilypond discussions, and it's probably the main reason why people get demotivated and discouraged. When someone comes up with an initiative, the reaction often _sounds like_ oh no, another enthusiastic guy. his ideas can cause us trouble and drain our precious resources. how can we save lilypond from him? instead of it's nice that you want to help. let's think how we can ensure that this will indeed be a benefit for lilypond. Probably the intentions of the people who reply are different, but that's how it sounds like to me. A few examples. Keep in mind that this is just my impression (the intentions of people who replied were probably different, but i cannot read their minds), and of course not all replies were like this: - lilypond blog: let's not put it on the website, because it will soon die and make us look silly. and it will introduce a security danger. - smufl: the reply to Urs' suggestion was mostly that'll cause us trouble and additional work, and we will be exploited by evil Steinberg - colorful make: the reaction was oh no, it will complicate our building process - snippets: the reaction was we don't need this, and it will be difficult, and we don't want to learn git. - github: changing our workflows will cause us trouble. I will participate as usual, although noting that my summer vacation ends this weekend. ok. I was simply reiterating something that Graham said to me on a number of occasions - don't assume that the work you do will be accepted - it's always possible that anything done on a collaborative project won't be. Patches are criticised, changed and occasionally junked, and the same can apply to proposals for changes in tools and processes - so don't become too committed and expend more work than you can afford to lose. Ever. Yes, i know. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Jan Nieuwenhuizen jann...@gnu.org writes: Janek Warchoł writes: Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? You may want to study - plain email-based patch submission using a benevolent dictator, ie, use git the way it was designed and is still used by the creators (linux, git). git's development itself is less dictator-specific than Linux' development, I think. This is also a bit of a red herring since our Contributor's Guide does _not_ ask for using the issue tracker (in fact, the issue tracker itself quite clearly states that users should not enter issues themselves). It can be argued that Email-based patch submission _is_ already what we propose, and we have the bug-squad as an interface into the issue tracking system from there. Part of the reason is actually that I started contributing patches a few years ago to LilyPond when there was nothing like the bug squad around, and after a while of contributions seemingly going down the drain without anybody who could be interested in them, getting really and quite obnoxiously pissed. So Graham organized the infrastructure where this would not easily happen again in the same manner, and the Contributor's Guide reflects it. But we haven't exactly seen a flurry of patches from newcomers appearing on the lists. Of course, part of the reason is that any good mailing list citizen will, before contributing, study some of the mailing list archives to figure out how things are usually done. And of course, studying our mailing list histories does not suggest that just submit a git patch series is a viable thing to do. So should our finally selected issue/review tool try _faking_ that appearance? Maybe. No idea. Perhaps we are overthinking this. At any rate, looking at options for more Git-centric tools than Rietveld can't do much harm. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 14:26, David Kastrup wrote: So Graham organized the infrastructure where this would not easily happen again in the same manner, and the Contributor's Guide reflects it. But we haven't exactly seen a flurry of patches from newcomers appearing on the lists. Of course, part of the reason is that any good mailing list citizen will, before contributing, study some of the mailing list archives to figure out how things are usually done. There may be another side to this. Post-GitHub there has been a pretty substantial increase in the user-friendliness of DVCS. What's currently advocated in the Contributors' Guide stands in stark contrast to the ease of contribution (and contribution management) that many people experience as the norm now. I'll give one example, because it's not clear to me that people have understood my past objections to git-cl etc. Here's a currently-open pull request of mine in another project that I contribute to: https://github.com/D-Programming-Language/phobos/pull/1533 You'll see that below the summary there is a report from the project auto-testing facility, with a link to a more detailed overview of the test results. What that means is that -- as a contributor -- I just submit a pull request via GitHub's UI. Testing is taken care of for me, and the feedback is there and integrated into my pull request for me to read and (if necessary) respond to. Or, if I were a reviewer, I again wouldn't need to worry about the testing, except as information useful for my review. In other words testing is a completely automated process that requires no manual intervention from anyone and no changes to the standard GitHub workflow. Contrast that with git-cl, and also bear in mind how user-friendly GitHub makes pull request submission and review. Unfortunately in this case the tool is a custom-written one for the project, because they had some very specific requirements and at the time no one tool supported all of them. It's possible of course that now the existing tools would satisfy what they needed. So, it's not likely to be directly useful for Lilypond, but it _is_ a very good model of how testing can be integrated into code review in a non-intrusive way. Similarly, the project's bugzilla listens in on pull requests and can be automatically updated when an appropriate pull request lands (the requirement is that the pull request title contain the issue number, so in this case it's not 100% automatic, but then, how could it be?). All of this is orders of magnitude more user-friendly than what Lilypond currently operates and I don't think I'm wrong in saying that this kind of easy DVCS experience is now the expected norm for many developers. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 13:56, Phil Holmes wrote: As far as I'm concerned, Google Code could be changed. I find its restriction on attachments annoying. However, a replacement would have to be able to import _all_ the issues lodged there with all their detail and attachments, and provide similar facilities. If it made other stuff easier, great. Good. That should make the range of available solutions much broader. I'd see the way to approach this as in 3 stages: (1) propose the architecture of the solution and present a prototype with a toy project just so that everyone can try it out from a user perspective. (2) if people like it, work to get a prototype set up that works with the Lilypond codebase. (3) if people still like that, do any necessary work like importing issues, etc. and switch over to the new system. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 11:48, Janek Warchoł wrote: David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? GitLab: http://gitlab.org/ Looks more feature-complete and user-friendly than Gitorious (it's got issue tracking as well as code hosting built in). You can use a hosted version (gitlab.com) or host your own version. It's MIT-licensed. They do a Red Hat-y kind of thing where they have an Enterprise Edition as well as Community Edition, but so far as I can tell from this summary, it's still MIT-licensed: http://www.gitlab.com/features/ ... so there shouldn't be any GNU/FSF-related political objections here. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: LilyPond Development Team lilypond-devel@gnu.org; David Kastrup d...@gnu.org; Joseph Wakeling joseph.wakel...@webdrake.net; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 1:06 PM Subject: Re: improving our contributing tools and workflow Hi, to make things clear: i do not intend to attack anyone personally, or imply that anyone has bad will or malicious intentions. I only want to explain how the situation looks like from my point of view. 2013/9/26 Phil Holmes m...@philholmes.net: Janek wrote: 2013/9/26 Phil Holmes m...@philholmes.net: Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek I don't see why you would get that impression. Because your message sounds pessimistic. It sounds like you consider it likely that my attempt to do something good will fail. It sounds like you are not concerned with ensuring that this initiative suceeds and brings benefit to all, but rather you are thinking about the damage and problems it can bring. I thought I made this clear - I was repeating something Graham said to me on a number of occasions. He would argue it was realistic, not pessimistic. You have to be aware of the fact that, simply by working hard on a problem does not guarantee that the effort expended will be rewarded. Here's a direct quote from him - clearly you don't fall into the category of new contributor, but the warning still applies: We've had bad experiences where a helpful and enthusiastic new contributor misunderstood the instructions, ran off and did 5 hours of work instead of 10 minutes, and none of the main developers wanted to take the time to deal with the results of the 5-hour work, so the whole thing was wasted. (literally wasted, as in the project would have received more benefit from the 10-minute job instead of the 5-hour work) Check the results of the grand regression test review. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: There may be another side to this. Post-GitHub there has been a pretty substantial increase in the user-friendliness of DVCS. What's currently advocated in the Contributors' Guide stands in stark contrast to the ease of contribution (and contribution management) that many people experience as the norm now. Just to give some perspective: let's assume LilyPond development were entirely moved to GitHub. How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 14:52, Phil Holmes wrote: I thought I made this clear - I was repeating something Graham said to me on a number of occasions. He would argue it was realistic, not pessimistic. You have to be aware of the fact that, simply by working hard on a problem does not guarantee that the effort expended will be rewarded. Here's a direct quote from him - clearly you don't fall into the category of new contributor, but the warning still applies: We've had bad experiences where a helpful and enthusiastic new contributor misunderstood the instructions, ran off and did 5 hours of work instead of 10 minutes, and none of the main developers wanted to take the time to deal with the results of the 5-hour work, so the whole thing was wasted. (literally wasted, as in the project would have received more benefit from the 10-minute job instead of the 5-hour work) Check the results of the grand regression test review. This risks becoming another corrosive discussion, so please understand that what I say next is not intended as an attack on anyone here and is meant in a spirit of hope for Lilypond's prosperous future. There is another possible response to such a situation, and it's: Oh wow, this person put a load of work in, they're obviously really committed and enthusiastic. OK, let's use these problems with what they've done as an opportunity to educate them better about how Lilypond works and how to avoid these kinds of problem in the future, and make them feel that we really value the time they've put in and want to repay them in kind. Now, I'm not assuming that no one has ever done this. I rather imagine it's been tried and that the resulting workload (probably mostly Graham's) has been overwhelming and that in fact there is no guarantee that it pays off in terms of another long-term contributor -- so people have been discouraged from this approach by hard experience. But I still think that it's possible to approach contributors with enthusiastic caution rather than lowered expectations, which are demoralizing for everyone. FWIW I think automated testing of pull requests is helpful here because test failures are impersonal and encourage the contributor to pro-actively sort out the problems in their code without having to be told -- there's not the same sense of personal rejection. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 15:04, David Kastrup wrote: How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? Don't know. Most of my potential contributions to Lilypond are likely to be documentation -- among other things I'd like to revisit and finish up the Contemporary Music section. But in a way I think this is the point -- I'm likely to continue to be an occasional contributor, sending something in when I have something I'm enthusiastic about when I have time and space to work on it. As things stand it's difficult to get that enthusiasm because there's a load of finnicky and annoying things involved with making a submission. If the ease of contribution was comparable to GitHub, I'd feel a lot better about doing so. I do appreciate your offer to just send patchlists to the mailing list and let you guys handle them, and I will try and do that, but it's still not as nice as a good code-hosting system. By the way, I'm not advocating GitHub as a solution. I'm pointing out GitHub as a now typical example of typical user experience contributing to free software projects. I also think that kind of usability would also pay off for you and other core developers and code reviewers, even if there are is no substantial increase in patch submission. I can understand if you don't see things the same way, though. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: Now, I'm not assuming that no one has ever done this. I rather imagine it's been tried and that the resulting workload (probably mostly Graham's) has been overwhelming and that in fact there is no guarantee that it pays off in terms of another long-term contributor -- so people have been discouraged from this approach by hard experience. But I still think that it's possible to approach contributors with enthusiastic caution rather than lowered expectations, which are demoralizing for everyone. Well, you think that it's better to demoralize existing developers rather than hypothetical would-be contributors nobody knows. How many patches would you expect to be contributing per month to LilyPond when it would use the code management systems you prefer? FWIW I think automated testing of pull requests is helpful here because test failures are impersonal and encourage the contributor to pro-actively sort out the problems in their code without having to be told -- there's not the same sense of personal rejection. We have automated tests of contributions already. Before telling everybody how to do everything better, how about making yourself acquainted with how we are doing things? Perhaps easiest done by contributing a few patches to the lists in the manner you like, and see what progress they make through the system? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 15:23, David Kastrup wrote: Well, you think that it's better to demoralize existing developers rather than hypothetical would-be contributors nobody knows. This is going to be a toxic direction of discussion if we pursue it, so I won't respond, except to say that it is not my intention to demoralize anyone, and I'm sorry if anyone does feel attacked or demoralized by what I've said here. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net To: David Kastrup d...@gnu.org Cc: Jan Nieuwenhuizen jann...@gnu.org; Janek Warchoł janek.lilyp...@gmail.com; LilyPond Development Team lilypond-devel@gnu.org; Phil Holmes m...@philholmes.net; Graham Percival gra...@percival-music.ca Sent: Thursday, September 26, 2013 2:22 PM Subject: Re: improving our contributing tools and workflow On 26/09/13 15:04, David Kastrup wrote: How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? Don't know. Most of my potential contributions to Lilypond are likely to be documentation -- among other things I'd like to revisit and finish up the Contemporary Music section. That would be something that we desperately need. The NR documentation on Contemporary Notation is shockingly poor. I would be prepared to accept almost any form of input from you with the words that improve that section of the NR and would be happy to type git cl upload on your behalf, in order to get the patches reviewed. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Phil Holmes wrote Thursday, September 26, 2013 3:11 PM - Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net On 26/09/13 15:04, David Kastrup wrote: How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? Don't know. Most of my potential contributions to Lilypond are likely to be documentation -- among other things I'd like to revisit and finish up the Contemporary Music section. That would be something that we desperately need. The NR documentation on Contemporary Notation is shockingly poor. I would be prepared to accept almost any form of input from you with the words that improve that section of the NR and would be happy to type git cl upload on your behalf, in order to get the patches reviewed. Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26/09/13 16:37, Trevor Daniels wrote: Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net To: Trevor Daniels t.dani...@treda.co.uk; Phil Holmes m...@philholmes.net; David Kastrup d...@gnu.org Cc: LilyPond Development Team lilypond-devel@gnu.org Sent: Thursday, September 26, 2013 4:09 PM Subject: Re: improving our contributing tools and workflow On 26/09/13 16:37, Trevor Daniels wrote: Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think it's waiting for someone to propose how it could be represented in LilyPond. If _someone_ were to do that, it might progress - it was only a few months ago it was last looked at. Good job I didn't get discouraged by the problems with piano pedal notation. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
On 26/09/13 17:16, Phil Holmes wrote: I think it's waiting for someone to propose how it could be represented in LilyPond. If _someone_ were to do that, it might progress - it was only a few months ago it was last looked at. Unfortunately, it was someone putting forward a workaround which I'd already proposed and found lacking, as it doesn't play nice with transposition :-( There was actually a patch submitted which tweaked the internal pitch representation appropriately: https://codereview.appspot.com/3789044/ ... but work on it seems to have been abandoned. _Conceptually_, the problem is this: Lilypond's pitch model consists of PITCH = STAFF_POSITION + ALTERATION where alteration is some fraction of a whole tone. (Actually there's no theoretical limit. You could have 3/2 of a tone, 2 tones ... although because the current transposition rules have a hard-coded limit of +/- 1, it's actually impossible in practice to transpose into keys where you might have triple sharps or flats. Hey, they do exist...:-) That model works fine for the standard 12 chromatic pitches, and it works fine for microtonal notation where each microtonal alteration is represented by a unique accidental. It fails for microtonal notation that essentially consists of PITCH = STAFF_POSTION + ALTERATION_0 + ALTERATION_1 + ... + ALTERATION_n of which quarter-tone arrow notation is one example (you have a first-order alteration which is the regular accidental, and a second-order alteration which is the up- or down- arrows). Ben Johnston's notation for extended just intonation is another example that very strongly relies on this hierarchy of pitch shading -- see e.g.: https://www.youtube.com/watch?v=0kVdgCWFJzE ... and http://notesfromadefeatist.blogspot.it/2010/01/just-intonation-notation.html for some explanation. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
On 26/09/13 17:35, Joseph Rushton Wakeling wrote: Unfortunately, it was someone putting forward a workaround which I'd already proposed and found lacking, as it doesn't play nice with transposition :-( There was actually a patch submitted which tweaked the internal pitch representation appropriately: https://codereview.appspot.com/3789044/ ... but work on it seems to have been abandoned. I should add that despite being the author of the original enhancement request, I don't think I was ever invited to take part in that review, which is a shame, as a number of participants seem to have misunderstood what I asked for. It may have just passed me by, though. I was working in a very intense and stressful job at the time and not following discussion very closely. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quarter-tone arrow notation [was: Re: improving our contributing tools and workflow]
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 26/09/13 17:35, Joseph Rushton Wakeling wrote: Unfortunately, it was someone putting forward a workaround which I'd already proposed and found lacking, as it doesn't play nice with transposition :-( There was actually a patch submitted which tweaked the internal pitch representation appropriately: https://codereview.appspot.com/3789044/ ... but work on it seems to have been abandoned. I should add that despite being the author of the original enhancement request, I don't think I was ever invited to take part in that review, which is a shame, as a number of participants seem to have misunderstood what I asked for. It may have just passed me by, though. I was working in a very intense and stressful job at the time and not following discussion very closely. You commented on the issue where this patch originated as late as July: URL:http://code.google.com/p/lilypond/issues/detail?id=1278#c7. So it's hard to argue that it was not discoverable to you. The creation of the issue tracker was pointed out to you in a direct reply by Valentin in URL:http://lists.gnu.org/archive/html/bug-lilypond/2010-09/msg00424.html. The discussion thread containing this pointer consists of four mails. Three of those mails were written by yourself, only the final reply with the pointer to the tracker issue was written by Valentin. I doubt that using a different tool would have changed your perception of never having been invited to take part in that review. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26 Sep 2013, at 17:16, Phil Holmes m...@philholmes.net wrote: On 26/09/13 16:37, Trevor Daniels wrote: Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think it's waiting for someone to propose how it could be represented in LilyPond. If _someone_ were to do that, it might progress - it was only a few months ago it was last looked at. It is easily solved by not using E24, as it does not sound good anyway. :-) But the problem is similar to that of enharmonic equivalences in E12: the staff system is not designed to express that. So first engrave as though they are different, end apply enharmonic equivalences at the end according to taste. In mathematical terms, the staff system is generated by an (abstract) minor second m and a major second M, all formal combinations r*m + s*M, where r, s runs through all integers: a free abelian group of rank 2. The degree d = deg(r*m + s*M) is the staff position. Each staff position has a note also of this form: subtract it, and what remains is a note of of degree d = 0. A sharp raises with M - m, and a flat lowers with the same amount. If d = 0, then r + s = 0, then so if s 0, add s sharps, and if r 0, add r flats. Now, this works also with microtonality: just add neutrals n = n_0, n_1, ..., n_k, which will result in a rank 2 + (k + 1) free abelian group of the pitches r*m + s*M + t*n + ... + t_k*n_k. Engrave the same way: compute degree d = deg(r*m + s*M + t*n + ... + t_k*n_k) := r + s + t + ... + t_k, which is the staff position, subtract the staff note, and what remains is a note of degree 0. It can be expressed by a suitable combinations of accidentals, where those that involve a neutral n_i are microtonal. Now, if you add a quarter-note, that is, a neutral n that when assigning pitches should have the value n = (m + M)/2. However, there is no way to express that in the staff system, just as it is not possible to express that 2*m = M. So in the staff system, the accidental going from m to n, the raising quarter-tone, will always be different from the one going from M to n, the lowering quarter-tone. Summarizing: E12 and E24 are tuning systems, which the staff system does not express. If one wants them to be properly expressed, invent a new notation system. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 13-09-26 03:48 AM, Janek Warchoł wrote: Hi all, after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. Well, I'm unskilled and uneducated in most areas useful to development and change management, but I'm offering to help in whatever way you think I can. Cheers, Colin -- A good juggler can always find work. - attributed to L. Pacioli (1445 - 1517) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On 26 Sep 2013, at 17:16, Phil Holmes m...@philholmes.net wrote: The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think it's waiting for someone to propose how it could be represented in LilyPond. For one microtonal accidental, one needs, in addition to the minor/major seconds m and M, a neutral second n. For a pitch x = r*m + s*M + t*n, compute its degree deg(x) := r + s + t, which is its staff position, and subtract the staff pitch. There remains a new pitch, which I also call x, but now with r + s + t = 0. As sharps/flats alter with a multiple of r - s, reduce using them so that only one of r, s is non-zero. Assume first that t = 1, i.e., one n. Then it must be either n - M or n - m. We have six microtonal symbols, sharp/natural/flat with up/down arrows, but it will, as we shall see, suffice with four. One way to make a choice is to conceptualize n as below or above (m + M)/2: if it is a small or large neutral. This choice is purely formal at this point, but will be of importance when plugging in values. If one thinks of n as between m and M, which is possible with actual values by reducing using sharps and flats, then n' := (m + M) - n (the minor third m3 complement) is also a neutral between m and M. If n is small, then n' is large, and vice versa. Returning to the situation above, assume n to be small. The up/down arrows will be thought of as changing with a small amount: n - m. There are two possibilities: n - m, and n - M. In the first case, n - m represents a small positive amount, so it is the natural with up arrow. In the second case, it is a large negative amount, so it is the flat with up arrow. Assume now that t = -1, so the two cases are m - n and M - n. The first case lowers with the small amount n - m, so it is a natural with a down arrow. And M - n raises with a large amount, so it must be a sharp with a down arrow. If the absolute value |t| of t is larger than 1, then one needs as many arrows as |t|: up if t is positive, and down if t is negative. Two symbols where not used: sharp with up arrow and flat with down arrow. But they conceptually fall without the region of raising a sharp M - m or lowering with a flat -(M - m), and can in fact be reduced using a natural with up/down arrow plus a sharp/flat. So here, one would need notation simplification algorithm. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
2013/9/26 Colin Campbell c...@shaw.ca: On 13-09-26 03:48 AM, Janek Warchoł wrote: Hi all, after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. Well, I'm unskilled and uneducated in most areas useful to development and change management, but I'm offering to help in whatever way you think I can. Excellent! We'll probably start by creating some test repositories on gitorious.org and gitlab.org, you may create an account already and look around. Meanwhile i'm going back to my little lilypond-vacation. see you soon, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
2013/9/27 Janek Warchoł janek.lilyp...@gmail.com: 2013/9/26 Colin Campbell c...@shaw.ca: Well, I'm unskilled and uneducated in most areas useful to development and change management, but I'm offering to help in whatever way you think I can. Excellent! We'll probably start by creating some test repositories on gitorious.org and gitlab.org, This should be gitlab.com (gitlab.org is a website about the software that runs gitlab.com). Sorry for confusion. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On Thu, Sep 26, 2013 at 03:12:27PM +0200, Joseph Rushton Wakeling wrote: On 26/09/13 14:52, Phil Holmes wrote: We've had bad experiences where a helpful and enthusiastic new contributor misunderstood the instructions, ran off and did 5 hours of work instead of 10 minutes, and none of the main developers wanted to take the time to deal with the results of the 5-hour work, so the whole thing was wasted. (literally wasted, as in the project would have received more benefit from the 10-minute job instead of the 5-hour work) This risks becoming another corrosive discussion, Then WTF are you starting it? There is another possible response to such a situation, and it's: Oh wow, this person put a load of work in, they're obviously really committed and enthusiastic. OK, let's use these problems with what they've done as an opportunity to educate them better about how Lilypond works and how to avoid these kinds of problem in the future, and make them feel that we really value the time they've put in and want to repay them in kind. Great answer! I'm so happy that YOU STEPPED FORWARD TO DO THIS IN THE PAST. The main developers owe NOTHING to somebody just because they did some work. I try to warn people NOT to waste their time, and Phil helpfully carries these warnings forward, and people criticize us for being demotivating. But I still think that it's possible to approach contributors with enthusiastic caution rather than lowered expectations, which are demoralizing for everyone. I breathlessly await the time when YOU do this, instead of complaining that existing developers don't do whatever you think they should be doing. Of course, first you need to learn how stuff works, and so far you've shown minimal interest in doing so. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
On Thu, Sep 26, 2013 at 02:05:44PM +0200, Jan Nieuwenhuizen wrote: - plain email-based patch submission using a benevolent dictator, ie, use git the way it was designed and is still used by the creators (linux, git). Are you volunteering to be that benevolent dictator? Spend, say, 15 hours a week reviewing and approving patches? I have no quarrel if you want to do that. The whole system is set up to minimize the demands on main developers. Any solution which shifts the burden away from contributors and onto main developers is IMO bad for LilyPond. We do *not* have an active body of main developers who want to spend time on administration. Does this place more burden on new contributors? yep. Do I think that's fair? yep. At least, it's certainly more fair than giving contributors expectations that the main developers are not willing to meet. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
