Re: we now have "lilypond" organization on GitHub

2013-09-22 Thread Urs Liska

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

2013-09-22 Thread David Kastrup
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

2013-09-22 Thread Phil Holmes
- 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-09-22 Thread 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.

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-09-22 Thread Janek Warchoł
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

2013-09-22 Thread Phil Holmes
- 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

2013-09-22 Thread David Kastrup
"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

2013-09-22 Thread David Kastrup
"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-09-22 Thread Federico Bruni
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)

2013-09-22 Thread vikreykja

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-09-22 Thread Janek Warchoł
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?

2013-09-22 Thread Janek Warchoł
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

2013-09-22 Thread 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.

- 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

2013-09-22 Thread Graham Percival
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

2013-09-22 Thread Urs Liska

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)

2013-09-22 Thread dak

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