Re: we now have "lilypond" organization on GitHub
Am 16.09.2013 12:50, schrieb David Kastrup: Graham Percival writes: On Mon, Sep 16, 2013 at 10:49:42AM +0200, David Kastrup wrote: What's wrong with GitHub, anyway? It requires separate accounts and credentials (much more likely to be a target for attacks), has its own "terms of service", may choose to discontinue projects based on commercial criteria, can cause tool lock-in and so on, relies on its own proprietary software. All the above is true, but github also provides a nicer way for developers to interact with git, by at least one order of magnitude. So the question is what we should be telling the Savannah operators to make working on GNU projects using Git more feasible. What about asking them to provide Gerrit as a service? As far as I've read: - LilyPond uses Rietveld, which isn't designed for git workflows. - Rietveld isn't integrated in the process of getting code into lilypond/master, but rather an artificial detour. - For example the issue of commit messages that are finally pushed and don't match the reviewed code is probably related to that. - Gerrit _is_ designed for git workflows. - You could grant developer accounts to, say, anybody expressing serious intentions to contribute - These could have the right to push the Gerrit - The core developers have the right to approve/reject proposals as well as pushing directly to the main repo - Approval of a patch immediately merges it into the main code base. - This would make the way for externals' code into the main code base more straightforward and transparent. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
Urs Liska writes: > Am 16.09.2013 12:50, schrieb David Kastrup: >> Graham Percival writes: >> >>> On Mon, Sep 16, 2013 at 10:49:42AM +0200, David Kastrup wrote: > What's wrong with GitHub, anyway? It requires separate accounts and credentials (much more likely to be a target for attacks), has its own "terms of service", may choose to discontinue projects based on commercial criteria, can cause tool lock-in and so on, relies on its own proprietary software. >>> All the above is true, but github also provides a nicer way for >>> developers to interact with git, by at least one order of >>> magnitude. >> So the question is what we should be telling the Savannah operators to >> make working on GNU projects using Git more feasible. >> > What about asking them to provide Gerrit as a service? As far as I understand, Gerrit is not something similar to the full "project management" flavor of GitHub but it would cover our Rietveld angle. > As far as I've read: > - LilyPond uses Rietveld, which isn't designed for git workflows. > - Rietveld isn't integrated in the process of getting code into > lilypond/master, > but rather an artificial detour. > - For example the issue of commit messages that are finally pushed > and don't match the reviewed code is probably related to that. > - Gerrit _is_ designed for git workflows. > - You could grant developer accounts to, say, anybody expressing > serious intentions to contribute > - These could have the right to push the Gerrit Ah, so make the gerrit repo a separate project with its separate user management? That could work. > - The core developers have the right to approve/reject proposals > as well as pushing directly to the main repo > - Approval of a patch immediately merges it into the main code base. Not sure about that, but one could work out procedures. One would have to see how large the part Gerrit takes in our submission process would turn out. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
- Original Message - From: "Urs Liska" To: "David Kastrup" Cc: "Julien Rioux" ; "LilyPond Developmet Team" ; "Han-Wen Nienhuys" Sent: Sunday, September 22, 2013 1:57 PM Subject: Re: we now have "lilypond" organization on GitHub Am 16.09.2013 12:50, schrieb David Kastrup: Graham Percival writes: On Mon, Sep 16, 2013 at 10:49:42AM +0200, David Kastrup wrote: What's wrong with GitHub, anyway? It requires separate accounts and credentials (much more likely to be a target for attacks), has its own "terms of service", may choose to discontinue projects based on commercial criteria, can cause tool lock-in and so on, relies on its own proprietary software. All the above is true, but github also provides a nicer way for developers to interact with git, by at least one order of magnitude. So the question is what we should be telling the Savannah operators to make working on GNU projects using Git more feasible. What about asking them to provide Gerrit as a service? As far as I've read: - LilyPond uses Rietveld, which isn't designed for git workflows. - Rietveld isn't integrated in the process of getting code into lilypond/master, but rather an artificial detour. - For example the issue of commit messages that are finally pushed and don't match the reviewed code is probably related to that. - Gerrit _is_ designed for git workflows. - You could grant developer accounts to, say, anybody expressing serious intentions to contribute - These could have the right to push the Gerrit - The core developers have the right to approve/reject proposals as well as pushing directly to the main repo - Approval of a patch immediately merges it into the main code base. - This would make the way for externals' code into the main code base more straightforward and transparent. Urs IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly in a Virtual Machine) provides git and git-cl. Git allows a developer to create a patch with 2 commands: git commit and git format-patch. That can be uploaded to Rietveld with a single command (possibly 2 commands, depending on what you were doing earlier). When the review is passed, it can be pushed to staging with 4 simple commands; or mailed to -devel for any active developer without push access - these are very rare. How hard is that? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
2013/9/22 Phil Holmes : > IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly > in a Virtual Machine) provides git and git-cl. Git allows a developer to > create a patch with 2 commands: git commit and git format-patch. That can > be uploaded to Rietveld with a single command (possibly 2 commands, > depending on what you were doing earlier). When the review is passed, it > can be pushed to staging with 4 simple commands; or mailed to -devel for any > active developer without push access - these are very rare. > > How hard is that? Hard. It takes at least an hour (more probably 2 hours) to install all this stuff and find and read relevant information (when i was installing lilydev my first time, it took me half of the night). And don't forget additional 5 GB of space you need for the VM, and that you have to use a completely new, unfamiliar environment (i.e. a new OS). Compare it to something like github (i'm not saying we should use github, that's just an example) when it takes 2 minutes and you can do everything in your browser (obviously, i'm speaking about small patches). To me, the difference is obvious. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
2013/9/22 Janek Warchoł : > 2013/9/22 Phil Holmes : >> IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly >> in a Virtual Machine) provides git and git-cl. Git allows a developer to >> create a patch with 2 commands: git commit and git format-patch. That can >> be uploaded to Rietveld with a single command (possibly 2 commands, >> depending on what you were doing earlier). When the review is passed, it >> can be pushed to staging with 4 simple commands; or mailed to -devel for any >> active developer without push access - these are very rare. >> >> How hard is that? > > Hard. It takes at least an hour (more probably 2 hours) to install > all this stuff and find and read relevant information (when i was > installing lilydev my first time, it took me half of the night). And > don't forget additional 5 GB of space you need for the VM, and that > you have to use a completely new, unfamiliar environment (i.e. a new > OS). > > Compare it to something like github (i'm not saying we should use > github, that's just an example) when it takes 2 minutes and you can do > everything in your browser (obviously, i'm speaking about small > patches). To me, the difference is obvious. Note that i'm speaking about how hard it is for new contributors. If we want to have them, it would be good to make contributing easy for them. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
- Original Message - From: "Janek Warchoł" To: "Phil Holmes" Cc: "Urs Liska" ; "David Kastrup" ; "Julien Rioux" ; "LilyPond Developmet Team" ; "Han-Wen Nienhuys" Sent: Sunday, September 22, 2013 4:30 PM Subject: Re: we now have "lilypond" organization on GitHub 2013/9/22 Phil Holmes : IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly in a Virtual Machine) provides git and git-cl. Git allows a developer to create a patch with 2 commands: git commit and git format-patch. That can be uploaded to Rietveld with a single command (possibly 2 commands, depending on what you were doing earlier). When the review is passed, it can be pushed to staging with 4 simple commands; or mailed to -devel for any active developer without push access - these are very rare. How hard is that? Hard. It takes at least an hour (more probably 2 hours) to install all this stuff and find and read relevant information (when i was installing lilydev my first time, it took me half of the night). And don't forget additional 5 GB of space you need for the VM, and that you have to use a completely new, unfamiliar environment (i.e. a new OS). Compare it to something like github (i'm not saying we should use github, that's just an example) when it takes 2 minutes and you can do everything in your browser (obviously, i'm speaking about small patches). To me, the difference is obvious. Janek Not comparing like with like. LilyDev provides a complete build environment; GitHub doesn't. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
"Phil Holmes" writes: > From: "Urs Liska" > >> Am 16.09.2013 12:50, schrieb David Kastrup: >> >>> So the question is what we should be telling the Savannah operators >>> to make working on GNU projects using Git more feasible. >>> >> What about asking them to provide Gerrit as a service? >> >> As far as I've read: >> - LilyPond uses Rietveld, which isn't designed for git workflows. >> - Rietveld isn't integrated in the process of getting code into >> lilypond/master, >> but rather an artificial detour. >> - For example the issue of commit messages that are finally pushed >> and don't match the reviewed code is probably related to that. >> - Gerrit _is_ designed for git workflows. >> - You could grant developer accounts to, say, anybody expressing >> serious intentions to contribute >> - These could have the right to push the Gerrit >> - The core developers have the right to approve/reject proposals >> as well as pushing directly to the main repo >> - Approval of a patch immediately merges it into the main code base. >> - This would make the way for externals' code into the main code base >> more straightforward and transparent. > > IMHO this is solving a problem that doesn't exist. Using LilyDev > (possibly in a Virtual Machine) provides git and git-cl. Git allows a > developer to create a patch with 2 commands: git commit and git > format-patch. That can be uploaded to Rietveld with a single command > (possibly 2 commands, depending on what you were doing earlier). When > the review is passed, it can be pushed to staging with 4 simple > commands; or mailed to -devel for any active developer without push > access - these are very rare. > > How hard is that? Well, try getting good musicians for a band where you'll be designing and building the instruments yourself. You'll find that it's usually less of a challenge to maintain a band with changing members if you let them play their own instruments. Even if your instruments are excellent. So there certainly is some merit to experimenting a bit with setups and see whether we find some combination of tools improving the likelihood of casual contributions. Now quite a bit of work on LilyPond still requires a rather special mixture of skill sets, so we should not set hopes too high. But it's likely that some experiments could get a good return for their efforts, and the Rietveld/Git combination is clearly not a marriage made in heaven. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
"Phil Holmes" writes: > - Original Message - > From: "Janek Warchoł" > To: "Phil Holmes" > Cc: "Urs Liska" ; "David Kastrup" ; > "Julien Rioux" ; "LilyPond Developmet Team" > ; "Han-Wen Nienhuys" > Sent: Sunday, September 22, 2013 4:30 PM > Subject: Re: we now have "lilypond" organization on GitHub > >> Compare it to something like github (i'm not saying we should use >> github, that's just an example) when it takes 2 minutes and you can >> do everything in your browser (obviously, i'm speaking about small >> patches). To me, the difference is obvious. > > > Not comparing like with like. LilyDev provides a complete build > environment; GitHub doesn't. Yup. So we are talking about creating untested patches here that eventually travel into the usual testing pipeline we use. Adding code comments and work on the documentation can actually be worthwhile with that kind of setup, and we have an actual pipeline for translations entirely separate from our issue submission system. It just shares the final lilypond-patchy-staging testing run which triggers pretty rarely nowadays, but still has provided a good safety net from breaking the code base for quite a while. Translations are a specific sort of documentation work, and other tasks might get away without a full LilyDev setup on the input end as well. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
2013/9/18 David Kastrup > Translation workflows don't use our > review system or issue trackers. > > And I don't even think they would benefit from it. If we take a look at > the few reasonably tightly tracked translations (French and Spanish, I > think), I very much doubt that you'd improve the quality of the work of > the respective translators by forcing a web frontend on them. > > And I doubt that a crowd-sourced German (say) translation would lead to > a consistent quality _unless_ several people get fully immersed into it > and again work at a level of thoroughness where web/crowdsourced > interfaces get more in the way than anything else. Program > documentation is not a Wikipedia-like task. > LilyPond documentation is so huge that sometimes I wish that more people could be involved.On the other hand, keeping the documentation consistent in the use of words is harder when several persons are working on it. I think that I like working in a team of two persons, even if this means that translation is proceeding slowly. Anyway, I don't know if a web interface would help much (at least for italian translation, as I don't see many users). The problem is translating.. and the quantity of lines to be translated: this is what may scare away potential contributors. I think also that the average LilyPond user can deal fairly well with unfriendly interfaces :-) For example, I recently asked the reviewer of my translation to use git[1] to send his corrections to me. He did it right since the beginning, even if he had no experience in commits and patches. [1] right after receiving 50 .diff files for each file in his previous review :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Stop \lyricmode { \skip 1.*3 } from failing. (issue 13256053)
I think a patch like this requires at least one regression test. https://codereview.appspot.com/13256053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
2013/9/22 David Kastrup : > "Phil Holmes" writes: >> IMHO this is solving a problem that doesn't exist. Using LilyDev >> (possibly in a Virtual Machine) provides git and git-cl. Git allows a >> developer to create a patch with 2 commands: git commit and git >> format-patch. That can be uploaded to Rietveld with a single command >> (possibly 2 commands, depending on what you were doing earlier). When >> the review is passed, it can be pushed to staging with 4 simple >> commands; or mailed to -devel for any active developer without push >> access - these are very rare. >> >> How hard is that? > > Well, try getting good musicians for a band where you'll be designing > and building the instruments yourself. > > You'll find that it's usually less of a challenge to maintain a band > with changing members if you let them play their own instruments. > > Even if your instruments are excellent. I couldn't have said it better! Janek :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
what happened to lilynet?
When i go to http://lilynet.net/, i see Fedora Test Page This page is used to test the proper operation of the Apache HTTP server after it has been installed. If you can read this page, it means that the web server installed at this site is working properly, but has not yet been configured It's like that for 4 days. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On Sun, Sep 22, 2013 at 02:57:42PM +0200, Urs Liska wrote: > Am 16.09.2013 12:50, schrieb David Kastrup: > >So the question is what we should be telling the Savannah operators to > >make working on GNU projects using Git more feasible. > > > What about asking them to provide Gerrit as a service? That's a possibility worth investigating. > - The core developers have the right to approve/reject proposals > as well as pushing directly to the main repo > - Approval of a patch immediately merges it into the main code base. I think you mean "push directly to staging". We don't want *any* patches going directly to master without checking that they still compile. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
On Sun, Sep 22, 2013 at 05:30:04PM +0200, Janek Warchoł wrote: > 2013/9/22 Phil Holmes : > > IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly > > in a Virtual Machine) provides git and git-cl. > > > > How hard is that? > > Hard. Good. (aside: note that my email about gerritt was aimed at moving lilypond development back to savannah, rather than spread across 3-4 companies/platforms) The experience from the Grand Documentation Project is that only 25% of new doc contributors ended up being a net benefit. Having an up-front hurdle, provided that it's well-explained, is a useful way to weed out people who are likely to fall into the remaining 75%. Granted, some of the 25% might also be turned away. So it's a question of the sum of values from all E(contributor | uses git-cl) % noting that the value from a contributor can be positive % or negative vs. sum of values from all E(contributor) I'm confident that the sum of the first is greater than the second. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
Am 23.09.2013 02:55, schrieb Graham Percival: On Sun, Sep 22, 2013 at 02:57:42PM +0200, Urs Liska wrote: Am 16.09.2013 12:50, schrieb David Kastrup: So the question is what we should be telling the Savannah operators to make working on GNU projects using Git more feasible. What about asking them to provide Gerrit as a service? That's a possibility worth investigating. - The core developers have the right to approve/reject proposals as well as pushing directly to the main repo - Approval of a patch immediately merges it into the main code base. I think you mean "push directly to staging". We don't want *any* patches going directly to master without checking that they still compile. I didn't elaborate on this because staging is by default integrated in the Gerrit workflow. Its standard setup http://gerrit-documentation.googlecode.com/svn/Documentation/2.7/intro-quick.html is having two stages: a) Code review Reviewers rate a patch with -2 up to +2 while the +/-1 are opinions. A suggested patch passes that stage with at least on +2 and _no_ -2 b) Verification This is suggested to be done automatically through build-tests or whatever is appropriate for the project, or semiautomatically. A patch that is 'verfied' will then be merged automatically from Gerrit to the main repository. The process can be configured to require less or more tests. E.g. removing the verification from Gerrit because it is done somewhere else. Urs PS (regarding Graham's other mail): The intention of suggesting Gerrit is to keep development where it currently is but streamlining contribution, especially for non-members. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stop \lyricmode { \skip 1.*3 } from failing. (issue 13256053)
Reviewers: Vik Reykja, Message: On 2013/09/22 22:30:51, Vik Reykja wrote: I think a patch like this requires at least one regression test. Well, actually the original lexer.ll patch would more likely have called for a regression test as it covers a lot more change. Would you want to propose one? A sole \lyricmode { \skip 1.*3 } seems a bit flimsy. Description: Stop \lyricmode { \skip 1.*3 } from failing. The problem was that the lexer preferred to match ".*" as a word since the matched pattern was longer than the explicit pattern matching ".". The word pattern is now amended so that it does not compete with the single-character patterns. Please review this at https://codereview.appspot.com/13256053/ Affected files (+1, -1 lines): M lily/lexer.ll Index: lily/lexer.ll diff --git a/lily/lexer.ll b/lily/lexer.ll index cebbd19627190c2504fbe5b547f8be83435cd16f..e896de3d638bc14a34c20037d7f72dfa4a9fae89 100644 --- a/lily/lexer.ll +++ b/lily/lexer.ll @@ -585,7 +585,7 @@ BOM_UTF8\357\273\277 yylval = SCM_UNSPECIFIED; return YYText ()[0]; } - [^$#{}\"\\ \t\n\r\f0-9]+ { + [^|*.=$#{}\"\\ \t\n\r\f0-9][^$#{}\"\\ \t\n\r\f0-9]* { /* ugr. This sux. */ string s (YYText_utf8 ()); yylval = SCM_UNSPECIFIED; ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel