Re: github mirror of lilypond?

[Werner LEMBERG]

> A problem with the policy "trivial things can just be pushed" is
> that "trivial" is open for interpretation.

Of course, but this shouldn't be a hindrance.

> Even a change that was intended to affect only comments could have a
> bad impact if, say, it inserts an accidental stray character and is
> not tested sufficiently.

I think that the benefit of having the stuff immediately in the
repository outweights the potential danger of breaking compilation.
Usually, a hotfix is a matter of seconds.

> James' report demonstrates that even if multiple devs agree that a
> change is trivial, it should still be tested before being pushed.

Well, this particular issue was *not* tagged as trivial, since it adds
a new regtest.


Werner

Re: github mirror of lilypond?

[David Kastrup]

Dan Eble  writes:

> On Jan 20, 2020, at 11:51, pkx1...@posteo.net wrote:
>> 
>> On 20/01/2020 16:16, Werner LEMBERG wrote:
 Trivial things from a developer with push access can be just pushed.
 Complex or otherwise contential things warrant a chance for
 developers to take a look at it.  "Half a chance" seems an
 unnecessary complication.
>>> Anyway, I was misled.  Han-Wen actually *did* create proper SF issues,
>>> which I seem to have missed because the gnu.org mailer had again
>>> delays, delivering messages in time-reversed order.
>>> 
>>> 
>>>Werner
>>> 
>> and on of them doesn't 'make/make test-baseline'.
>
>
> A problem with the policy "trivial things can just be pushed" is that
> "trivial" is open for interpretation.  Even a change that was intended
> to affect only comments could have a bad impact if, say, it inserts an
> accidental stray character and is not tested sufficiently.
>
> James' report demonstrates that even if multiple devs agree that a
> change is trivial, it should still be tested before being pushed.

It's worth noting that our staging/master setup means that changes _are_
tested before being ultimately pushed to the major work resource for
developers.  If this blows up, it blocks the staging pipeline.  With our
current rate of commits and staging tests, disentangling this tends to
be comparatively benign.

As long as nothing, however trivial, gets pushed to master without
testing, the consequences are at least kept in check mostly.

-- 
David Kastrup

Re: github mirror of lilypond?

[Dan Eble]

On Jan 20, 2020, at 11:51, pkx1...@posteo.net wrote:
> 
> On 20/01/2020 16:16, Werner LEMBERG wrote:
>>> Trivial things from a developer with push access can be just pushed.
>>> Complex or otherwise contential things warrant a chance for
>>> developers to take a look at it.  "Half a chance" seems an
>>> unnecessary complication.
>> Anyway, I was misled.  Han-Wen actually *did* create proper SF issues,
>> which I seem to have missed because the gnu.org mailer had again
>> delays, delivering messages in time-reversed order.
>> 
>> 
>>Werner
>> 
> and on of them doesn't 'make/make test-baseline'.


A problem with the policy "trivial things can just be pushed" is that "trivial" 
is open for interpretation.  Even a change that was intended to affect only 
comments could have a bad impact if, say, it inserts an accidental stray 
character and is not tested sufficiently.

James' report demonstrates that even if multiple devs agree that a change is 
trivial, it should still be tested before being pushed.
— 
Dan

Re: github mirror of lilypond?

[Dan Eble]

On Jan 20, 2020, at 11:40, Carl Sorensen  wrote:
> I agree.  And while comments during countdown are annoying and frustrating, 
> it's even more annoying and frustrating to have a commit reverted.  So I 
> prefer countdown to reversion.

+1
— 
Dan

Re: github mirror of lilypond?

[pkx166h]

On 20/01/2020 16:16, Werner LEMBERG wrote:
>> Trivial things from a developer with push access can be just pushed.
>> Complex or otherwise contential things warrant a chance for
>> developers to take a look at it.  "Half a chance" seems an
>> unnecessary complication.
> Anyway, I was misled.  Han-Wen actually *did* create proper SF issues,
> which I seem to have missed because the gnu.org mailer had again
> delays, delivering messages in time-reversed order.
>
>
> Werner
>
and on of them doesn't 'make/make test-baseline'.

James

Re: github mirror of lilypond?

[Carl Sorensen]

On 1/20/20, 9:07 AM, "lilypond-devel on behalf of Urs Liska" 
 wrote:

Am Montag, den 20.01.2020, 16:53 +0100 schrieb David Kastrup:
> David Kastrup  writes:
> 
> > Werner LEMBERG  writes:
> > 
> > > > > Han-Wen has recently pushed a bunch of changes directly to
> > > > > Rietveld, most of them quite uncontroversial.  I assume that
> > > > > this
> > > > > is as good as an e-mail :-)
> > > > > 
> > > > > I thus suggest that after his patches have been reviewed,
> > > > 
> > > > How are they going to get reviewed when there is nothing
> > > > pointing to
> > > > them?  How would anyone including Han-Wen know when the review
> > > > phase
> > > > ends?
> > > 
> > > Well, as has been pointed out, pull requests at github don't have
> > > 'review phases', and what we have here is comparable IMHO.
> > > 
> > > One developer (or maybe two, just to be sure) acknowledges the
> > > patch,
> > > and that's it.  Kind of a highway solution for trivial things.
> > 
> > Trivial things from a developer with push access can be just
> > pushed.
> > Complex or otherwise contential things warrant a chance for
> > developers
> > to take a look at it.  "Half a chance" seems an unnecessary
> > complication.
> 
> At any rate: we haven't had a protocol for patches not going through
> the
> regular process.  Maybe we should use the Signed-off-by: convention
> for
> such patches, including the original submitter and the LGTM
> votes?  It's
> probably mostly psychological, but it suggests a bit of
> accountability/responsibility.
> 

I would like to add to that. With my few contributions to the actual
LilyPond codebase I was several times hit hard by last-moment
objections in the countdown stage.

This is totally annoying and also frustrating - but what would be the
alternative? Obviously there was something that should not go into the
code base, and the fact that we're so few that not everyone has the
opportunity to look at all patches immediately should not be a
"justification" for letting stuff slip through.


I agree.  And while comments during countdown are annoying and frustrating, 
it's even more annoying and frustrating to have a commit reverted.  So I prefer 
countdown to reversion.

Thanks,

Carl

Re: github mirror of lilypond?

[Werner LEMBERG]

>> At any rate: we haven't had a protocol for patches not going
>> through the regular process.  Maybe we should use the
>> Signed-off-by: convention for such patches, including the original
>> submitter and the LGTM votes?  It's probably mostly psychological,
>> but it suggests a bit of accountability/responsibility.

This is OK with me.

> I would like to add to that. With my few contributions to the actual
> LilyPond codebase I was several times hit hard by last-moment
> objections in the countdown stage.
>
> This is totally annoying and also frustrating - but what would be
> the alternative? Obviously there was something that should not go
> into the code base, and the fact that we're so few that not everyone
> has the opportunity to look at all patches immediately should not be
> a "justification" for letting stuff slip through.

I think there is nothing we can do to prevent that.


Werner

Re: github mirror of lilypond?

[Werner LEMBERG]

> Trivial things from a developer with push access can be just pushed.
> Complex or otherwise contential things warrant a chance for
> developers to take a look at it.  "Half a chance" seems an
> unnecessary complication.

Anyway, I was misled.  Han-Wen actually *did* create proper SF issues,
which I seem to have missed because the gnu.org mailer had again
delays, delivering messages in time-reversed order.


Werner

Re: github mirror of lilypond?

[Urs Liska]

Am Montag, den 20.01.2020, 16:53 +0100 schrieb David Kastrup:
> David Kastrup  writes:
> 
> > Werner LEMBERG  writes:
> > 
> > > > > Han-Wen has recently pushed a bunch of changes directly to
> > > > > Rietveld, most of them quite uncontroversial.  I assume that
> > > > > this
> > > > > is as good as an e-mail :-)
> > > > > 
> > > > > I thus suggest that after his patches have been reviewed,
> > > > 
> > > > How are they going to get reviewed when there is nothing
> > > > pointing to
> > > > them?  How would anyone including Han-Wen know when the review
> > > > phase
> > > > ends?
> > > 
> > > Well, as has been pointed out, pull requests at github don't have
> > > 'review phases', and what we have here is comparable IMHO.
> > > 
> > > One developer (or maybe two, just to be sure) acknowledges the
> > > patch,
> > > and that's it.  Kind of a highway solution for trivial things.
> > 
> > Trivial things from a developer with push access can be just
> > pushed.
> > Complex or otherwise contential things warrant a chance for
> > developers
> > to take a look at it.  "Half a chance" seems an unnecessary
> > complication.
> 
> At any rate: we haven't had a protocol for patches not going through
> the
> regular process.  Maybe we should use the Signed-off-by: convention
> for
> such patches, including the original submitter and the LGTM
> votes?  It's
> probably mostly psychological, but it suggests a bit of
> accountability/responsibility.
> 

I would like to add to that. With my few contributions to the actual
LilyPond codebase I was several times hit hard by last-moment
objections in the countdown stage.

This is totally annoying and also frustrating - but what would be the
alternative? Obviously there was something that should not go into the
code base, and the fact that we're so few that not everyone has the
opportunity to look at all patches immediately should not be a
"justification" for letting stuff slip through.

Re: github mirror of lilypond?

[David Kastrup]

David Kastrup  writes:

> Werner LEMBERG  writes:
>
 Han-Wen has recently pushed a bunch of changes directly to
 Rietveld, most of them quite uncontroversial.  I assume that this
 is as good as an e-mail :-)

 I thus suggest that after his patches have been reviewed,
>>> 
>>> How are they going to get reviewed when there is nothing pointing to
>>> them?  How would anyone including Han-Wen know when the review phase
>>> ends?
>>
>> Well, as has been pointed out, pull requests at github don't have
>> 'review phases', and what we have here is comparable IMHO.
>>
>> One developer (or maybe two, just to be sure) acknowledges the patch,
>> and that's it.  Kind of a highway solution for trivial things.
>
> Trivial things from a developer with push access can be just pushed.
> Complex or otherwise contential things warrant a chance for developers
> to take a look at it.  "Half a chance" seems an unnecessary
> complication.

At any rate: we haven't had a protocol for patches not going through the
regular process.  Maybe we should use the Signed-off-by: convention for
such patches, including the original submitter and the LGTM votes?  It's
probably mostly psychological, but it suggests a bit of
accountability/responsibility.

-- 
David Kastrup

Re: github mirror of lilypond?

[David Kastrup]

Werner LEMBERG  writes:

>>> Han-Wen has recently pushed a bunch of changes directly to
>>> Rietveld, most of them quite uncontroversial.  I assume that this
>>> is as good as an e-mail :-)
>>>
>>> I thus suggest that after his patches have been reviewed,
>> 
>> How are they going to get reviewed when there is nothing pointing to
>> them?  How would anyone including Han-Wen know when the review phase
>> ends?
>
> Well, as has been pointed out, pull requests at github don't have
> 'review phases', and what we have here is comparable IMHO.
>
> One developer (or maybe two, just to be sure) acknowledges the patch,
> and that's it.  Kind of a highway solution for trivial things.

Trivial things from a developer with push access can be just pushed.
Complex or otherwise contential things warrant a chance for developers
to take a look at it.  "Half a chance" seems an unnecessary
complication.

-- 
David Kastrup

Re: github mirror of lilypond?

[Werner LEMBERG]

>> Han-Wen has recently pushed a bunch of changes directly to
>> Rietveld, most of them quite uncontroversial.  I assume that this
>> is as good as an e-mail :-)
>>
>> I thus suggest that after his patches have been reviewed,
> 
> How are they going to get reviewed when there is nothing pointing to
> them?  How would anyone including Han-Wen know when the review phase
> ends?

Well, as has been pointed out, pull requests at github don't have
'review phases', and what we have here is comparable IMHO.

One developer (or maybe two, just to be sure) acknowledges the patch,
and that's it.  Kind of a highway solution for trivial things.


Werner

Re: github mirror of lilypond?

[David Kastrup]

Werner LEMBERG  writes:

>>Send an email (must be less than 64 KB) to
>>  briefly explaining your work, with the
>> patch files attached.  Translators should send patches to
>> .  After your patches are reviewed, the
>> developers may push one or more of them to the main repository or
>> discuss them with you.
>
> Han-Wen has recently pushed a bunch of changes directly to Rietveld,
> most of them quite uncontroversial.  I assume that this is as good as
> an e-mail :-)
>
> I thus suggest that after his patches have been reviewed,

How are they going to get reviewed when there is nothing pointing to
them?  How would anyone including Han-Wen know when the review phase
ends?

> he should simply commit to `staging`.  If a developer has doubts, we
> can create an SourceForge issue to do it the normal way.
>
> Of course, this is a temporary measure until Janek finds and
>implements something better (see the Salzburg googledoc file posted
>recently for more).

-- 
David Kastrup

Re: github mirror of lilypond?

[Werner LEMBERG]

>Send an email (must be less than 64 KB) to
>  briefly explaining your work, with the
> patch files attached.  Translators should send patches to
> .  After your patches are reviewed, the
> developers may push one or more of them to the main repository or
> discuss them with you.

Han-Wen has recently pushed a bunch of changes directly to Rietveld,
most of them quite uncontroversial.  I assume that this is as good as
an e-mail :-)

I thus suggest that after his patches have been reviewed, he should
simply commit to `staging`.  If a developer has doubts, we can create
an SourceForge issue to do it the normal way.

Of course, this is a temporary measure until Janek finds and
implements something better (see the Salzburg googledoc file posted
recently for more).


Werner

Re: github mirror of lilypond?

[David Kastrup]

"Jürgen Reuter"  writes:

>Hi all,
>
>+1 (at least) from me for for:
>
>* Having a smooth integration of git repository, review process and
>verify build.  If this is (as I conclude from the discussions) not
>possible with hosting the git repository on savannah, then please
>consider hosting the repository on a different platform.
>
>* Using Gerrit as review system (maybe unless you know of another
>system with equally smooth integration with git; but I do not know of
>any such system).  I am using Gerrit (the "old" version) at work and I
>am fully satisfied with its integration with git and Jenkins.
>I still have here ~12 mostly small commits (tiny fixes / features,
>clean-ups, code doc clarifications, etc.) lying around locally on my
>machine for several years.  I did not push them so far as I was (and
>still am) really scared about the time that I have to invest to get
>these commits through this complex process, especially as I expect at
>least some of the commits not to pass in the first go, but expecting
>possibly controversial reviews.
>Maybe the current process feels not that complex if you are committing
>regularly.  But I perceive it as complex, especially with respect to
>the time that I fear to have to put into the process rather than being
>productive, given my very limited time budget.  And I think, other
>people perceive it similarly.

File: lilypond-contributor.info,  Node: How to make a patch,  Next: Emailing 
patches,  Up: Patches

How to make a patch
...

If you want to share your changes with other contributors and
developers, you need to generate _patches_ from your commits.  We prefer
it if you follow the instructions in *note Uploading a patch for
review::.  However, we present an alternate method here.

   You should always run ‘git pull -r’ (translators should leave off the
‘-r’) before doing this to ensure that your patches are as current as
possible.

   Once you have made one or more commits in your local repository, and
pulled the most recent commits from the remote branch, you can generate
patches from your local commits with the command:

 git format-patch origin

   The ‘origin’ argument refers to the remote tracking branch at
‘git.sv.gnu.org’.  This command generates a separate patch for each
commit that’s in the current branch but not in the remote branch.
Patches are placed in the current working directory and will have names
that look something like this:

 0001-Doc-Fix-typos.patch
 0002-Web-Remove-dead-links.patch
 ⋮

   Send an email (must be less than 64 KB) to 
briefly explaining your work, with the patch files attached.
Translators should send patches to .  After
your patches are reviewed, the developers may push one or more of them
to the main repository or discuss them with you.

>And of course, a big thank you to all of you that do all the great
>work, that I really appreciate!  But to attract more developers and /
>or re-animate retired developers, I am pretty sure that the process has
>to be simplified for potential "casual" committers like me that will
>contribute only now and then.

The above does not look all that complex to me.

-- 
David Kastrup

Re: github mirror of lilypond?

[Jürgen Reuter]

   Hi all,

   +1 (at least) from me for for:

   * Having a smooth integration of git repository, review process and
   verify build.  If this is (as I conclude from the discussions) not
   possible with hosting the git repository on savannah, then please
   consider hosting the repository on a different platform.

   * Using Gerrit as review system (maybe unless you know of another
   system with equally smooth integration with git; but I do not know of
   any such system).  I am using Gerrit (the "old" version) at work and I
   am fully satisfied with its integration with git and Jenkins.
   I still have here ~12 mostly small commits (tiny fixes / features,
   clean-ups, code doc clarifications, etc.) lying around locally on my
   machine for several years.  I did not push them so far as I was (and
   still am) really scared about the time that I have to invest to get
   these commits through this complex process, especially as I expect at
   least some of the commits not to pass in the first go, but expecting
   possibly controversial reviews.
   Maybe the current process feels not that complex if you are committing
   regularly.  But I perceive it as complex, especially with respect to
   the time that I fear to have to put into the process rather than being
   productive, given my very limited time budget.  And I think, other
   people perceive it similarly.

   And of course, a big thank you to all of you that do all the great
   work, that I really appreciate!  But to attract more developers and /
   or re-animate retired developers, I am pretty sure that the process has
   to be simplified for potential "casual" committers like me that will
   contribute only now and then.

   Best wishes,
   Jürgen

Re: github mirror of lilypond?

[David Kastrup]

pkx1...@posteo.net writes:

> On 19/01/2020 07:41, Han-Wen Nienhuys wrote:
>>
>> I don't how this done today with LilyPond (manually?). Doing this
>> manually is tedious and error-prone busywork. 
>
> Thanks for the compliment Han-wen.
>
> Much appreciated.
>
> regards
>
> James 'the error-prone busy-worker'.

And doing quite an amazing bit of work.  Automation was better at one
point of time, but the visual comparison of results at least cannot be
replaced, and the sleuth work for pinpointing actual causes of problems
is also something that has become a rather remarkable improvement over
what automation could deliver.

This certainly is not about improving the contributions to our process
that you deliver, it's about making them more effective in order to
attract more new and possibly old developers.

Whether this is effective is something we'll have to see: while our
contribution procedures may appear baroque, the code base to actual work
on is byzantine in comparison.

-- 
David Kastrup

Re: github mirror of lilypond?

[David Kastrup]

Carl Sorensen  writes:

> On 1/19/20, 3:33 PM, "Han-Wen Nienhuys"  wrote:
>
> On Sun, Jan 19, 2020 at 8:41 AM Han-Wen Nienhuys  
> wrote:
> > > I agree.  IMHO, the main repository should stay at Savannah, though.
> >
> > I strongly disagree with this.
> >
> > If we are serious about code review (and it seems that we are), the
> > code review has to be integrated with the git hosting system. With the
> > current setup, there needs to be infrastructure that takes a patch for
> > review, applies it to source tree, runs tests, and then reports back.
> > On submission, something has to apply the patch, and push the result
> > to the git master branch.
> 
> And come to think of it, it is also the reason for an incredible
> oddity in our current process which is the "countdown". Normally, once
> a change has been reviewed as OK and passed CI, it is just submitted.
> But in the past, they would enter some limbo (because nobody would do
> the work to submit them), and so we had to institute a countdown
> process, which means that it takes a minimum of 2 days before a
> contributor can see their patch go live.
>
> No, the "countdown" is a last chance for people to comment before the
> patch is approved.  No single individual can approve a patch.
> Multiple reviewers can say it looks good, but a single reviewer can
> point out a problem that requires review.  No specific set of review
> approvals constitute acceptance.
>
> So "countdown" serves as a warning to anybody who might have issues.
> Essentially "if you don’t comment in the next two days, it will be
> approved.  So if you care, you'd better review it right now."

The countdown is a compromise between contributor and other developers'
needs.  It certainly is a nuisance but has been quite valuable.  The
previous process requiring explicit developer acknowledgment led to
patches "in limbo" for weeks without any feedback.  I have a Guile core
patch that has not gotten a review or comment by Andy Wingo for about
5 years or so now.  In contrast to that, our process is comparably fast
and benign.

-- 
David Kastrup

Re: github mirror of lilypond?

[Carl Sorensen]

On 1/19/20, 3:33 PM, "Han-Wen Nienhuys"  wrote:

On Sun, Jan 19, 2020 at 8:41 AM Han-Wen Nienhuys  wrote:
> > I agree.  IMHO, the main repository should stay at Savannah, though.
>
> I strongly disagree with this.
>
> If we are serious about code review (and it seems that we are), the
> code review has to be integrated with the git hosting system. With the
> current setup, there needs to be infrastructure that takes a patch for
> review, applies it to source tree, runs tests, and then reports back.
> On submission, something has to apply the patch, and push the result
> to the git master branch.

And come to think of it, it is also the reason for an incredible
oddity in our current process which is the "countdown". Normally, once
a change has been reviewed as OK and passed CI, it is just submitted.
But in the past, they would enter some limbo (because nobody would do
the work to submit them), and so we had to institute a countdown
process, which means that it takes a minimum of 2 days before a
contributor can see their patch go live.

No, the "countdown" is a last chance for people to comment before the patch is 
approved.  No single individual can approve a patch.  Multiple reviewers can 
say it looks good, but a single reviewer can point out a problem that requires 
review.  No specific set of review approvals constitute acceptance.

So "countdown" serves as a warning to anybody who might have issues.  
Essentially "if you don’t comment in the next two days, it will be approved.  
So if you care, you'd better review it right now."

Our current process is:

Contributor submits patch -- status is set to "New"

James applies the patch to the source tree, runs tests, and reports back.
If tests pass, status is set to "Review"
If tests fail, status is set to "Needs work".  Modified patches in 
"Needs Work" status go back to "New".

Review period is entered, and James (the patch meister) monitors the comments.  
After the specified period, if all the comments are positive, the status is set 
to "Countdown".

If there are a significant negative comments, the status is set to "Needs 
work".  Modified patches in "Needs work" status go back to "New"

If the countdown period passes with no negative comments, the status is set to 
"Push".

I don't think it's accurate to say patches are in limbo.  

Thanks,

Carl




-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: github mirror of lilypond?

[Han-Wen Nienhuys]

On Sun, Jan 19, 2020 at 8:41 AM Han-Wen Nienhuys  wrote:
> > I agree.  IMHO, the main repository should stay at Savannah, though.
>
> I strongly disagree with this.
>
> If we are serious about code review (and it seems that we are), the
> code review has to be integrated with the git hosting system. With the
> current setup, there needs to be infrastructure that takes a patch for
> review, applies it to source tree, runs tests, and then reports back.
> On submission, something has to apply the patch, and push the result
> to the git master branch.

And come to think of it, it is also the reason for an incredible
oddity in our current process which is the "countdown". Normally, once
a change has been reviewed as OK and passed CI, it is just submitted.
But in the past, they would enter some limbo (because nobody would do
the work to submit them), and so we had to institute a countdown
process, which means that it takes a minimum of 2 days before a
contributor can see their patch go live.


-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: github mirror of lilypond?

[Han-Wen Nienhuys]

On Sun, Jan 19, 2020 at 12:14 PM Jonas Hahnfeld  wrote:
> General things first: The UI of Gerrit v3 seems to be much nicer than
> its previous version. Back then I found it incredibly hard to just look

thanks, I'll pass on the compliments.

> > In the above, I sent a stack of 7
> > commits for review at once.
>
> That's where "Relation chain" and "Submitted together" come into play,
> right? Funnily enough, "Submitted together" only shows predecessors...

Yes, if you submit the change of the top of the stack, you typically
submit all the predecessors.

> From a high level, I think Gerrit expects reviewers to accept each
> change individually. Does this really model the development style of
> LilyPond?

It's rather the opposite. Since Gerrit has the actual git commits, you
can rebase, and cherry pick changes from the UI, so you can submit
changes individually, even if their predecessors are missing
approvals.

Rietveld has no notion of dependent changes at all.

> Being relatively new, I got the perception that we usually
> split up a change into logically grouped commits. Eventually I want
> them to be viewed and submitted as one push, not one by one as the
> individual commits are accepted.

Yes, you can do that too. see

https://gerrit.googlesource.com/gerrit/+/9e47119d65b7ac7ab4db568456e17b556c207f59

which merges in 4 changes in one go.

> In that regard I really like how Pull Requests / Merge Requests in
> GitHub / GitLab / gitea work: You can look at commit granularity if you
> want to, but in the end you accept the whole thing. That's also good
> because changes to a predecessor might require reworking later patches.

I find PRs unwieldy for complex changes, because the GH interface
doesn't let you compare different commits in the PR to each other. For
example, the change

  https://git.eclipse.org/r/c/146568/

went through 92 rounds of review before it was merged. The GH UI isn't
really suited to this much back and forth on a review.

That said, as said before, I like gerrit, but I think the benefits of
switching to a platform (like GH or GL) outweigh the limitations of
their review experience for LilyPond.


> > Working with a single commit requires using commit --amend and with
> > multiple commits requires using rebase -i, both of which Git newbies
> > seems a little scared of.
>
> Right, but as most other tools you can probably just upload and update
> a patch file somewhere? That would be the easiest solution for new
> contributors.

Gerrit has a complete git server inside. You don't upload patches, but
you do a git push of your to-be-reviewed code instead. Other people
can then clone your code (see the command under the "download"
button.)

> Jonas
>
> >
> > On Sun, Jan 19, 2020 at 4:34 AM Karlin High <
> > karlinh...@gmail.com
> > > wrote:
> > > On 1/18/2020 4:59 AM, Jonas Hahnfeld via Discussions on LilyPond
> > > development wrote:
> > > > I strongly dislike Gerrit, it's really hard to learn and even after
> > > > some time I still can't figure out how to use it correctly.
> > >
> > > This topic is outside my expertise. But I understood that Gerrit and
> > > Rietveld are both descendants of Google's proprietary internal-use
> > > Mondrian code review tool.
> > >
> > > <
> > > https://www.gerritcodereview.com/about.html
> > > >
> > >
> > > I see quite a few patches lately that show Jonas Hahnfeld as the author...
> > >
> > > <
> > > https://codereview.appspot.com/user/hahnjo
> > > >
> > > <
> > > https://git.savannah.gnu.org/cgit/lilypond.git/log/?qt=author=Jonas+Hahnfeld
> > > >
> > >
> > > ...so I'm wondering if Rietveld has you suffering in silence ;) or if
> > > the fork and rewrite mentioned on that Gerrit "about" page has greatly
> > > diverged the user experiences of these respective products?
> > > --
> > > Karlin High
> > > Missouri, USA
> >
> >
> >
> >



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: github mirror of lilypond?

[Han-Wen Nienhuys]

I didn't mean to discredit the work that you do; in the current setup
your work is incredibly important, and please accept my apologies if I
offended you.

I meant to say that we have few contributors, so if we want to be as
effective as possible, we should automate as much as possible.

On Sun, Jan 19, 2020 at 7:13 PM  wrote:
>
> On 19/01/2020 07:41, Han-Wen Nienhuys wrote:
> >
> > I don't how this done today with LilyPond (manually?). Doing this
> > manually is tedious and error-prone busywork.
>
> Thanks for the compliment Han-wen.
>
> Much appreciated.
>
> regards
>
> James 'the error-prone busy-worker'.
>
>
>


-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: github mirror of lilypond?

[David Kastrup]

Urs Liska  writes:

> Am Sonntag, den 19.01.2020, 20:31 + schrieb Erlend Aasland:
>> True. But, there are GitHub alternatives that are free, for example
>> Gitea.
>
> Yes, but self-hosting a Git repository software (well, I have a Gitea
> instance on my server) is an involved thing, and I don't think it's
> reasonable to expect putting that burden and responsibility on
> someone's personal shoulders.
> I don't think that's an option for us either, although it would be the
> way to go on a conceptual level. We'd have some money to pay for the
> server and the maintenance...

Janek offered today to invest the work getting to a solution if he's not
getting bogged down in arguments.  It is obvious that our current
available resources will not result in an ethically as well as
technically gratifying solution and our current setup, while marvelously
supported by several volunteers, does not seem well-suited for
attracting new contributors or even reattracting dormant ones, and it's
not like the current SourceForge/Google mixture registers high in the
"GNU project standards supportive" category.

So I think we should give serious consideration for what he comes up
with.  The GNU maintainer guidelines have some comments about hosting
choices: I'll try digging them up tomorrow and there may be some point
to avoiding the "worst offender" category.

But we already ran out of steam in the self-hosting challenge on Allura:
there is not much of a sense in aiming higher than we can expect to
shoot eventually.

-- 
David Kastrup

Re: github mirror of lilypond?

[David Kastrup]

Erlend Aasland  writes:

> (Sorry for the messed up indent/quote level. Apple Mail is a pain in
> the butt sometimes.)

The previous one had an indiscriminate plain text and a properly
indented HTML variant.  This one has only an indiscriminate plain text.
Make no mistake: I prefer plain text.  But...

I decided to delete the following quoted plain text (it's useless
anyway) and append a rendition of the indented HTML text.

Thus spake Erlend:

On 19 Jan 2020, at 18:19, David Kastrup  wrote:
What is of concern is the whole metadata about issues and their
handling and resolution, the stuff you propose moving to GitHub
in the first place.

Just for the record; I’m not suggesting GitHub as the one and only
alternative. I think I mentioned some of the GH alternatives in my
original email, IIRC.

I understand the concern about metadata and such, but a lot of that
information is already present in the commits (both as metadata in
the commits and as commit messages), so I guess you’ve already put
uncomfortably much information in there already…

The current use of Savannah hosting for that reason is not a
whole lot more than a vote of confidence to GNU/FSF/Stallman
(which at the current point of time are more separate entities
than they historically were) but not of practical importance.

True.

Our current ties to Google (via Rietveld) and SourceForge (for
Allura/issue tracking) are practically speaking more tenuous to
replace.  Of course they deserve replacing, but doing so by
picking GitHub would definitely be a much more invasive step for
the project than just entertaining a Git mirror.

True.

Make no mistake: our current dependencies in that regard are of
lukewarm quality concerning the "Free Software" regard and are a
crutch technically.  So a change is definitely called for.

True.

But I don’t consider GitHub a nobrainer or I'd likely have an
account there: I chose not to the last time I read their terms
of use, and while I haven't rechecked since then, its change of
ownership does not inspire confidence.  Now of course the terms
and guarantees then might have been chosen in order not to
interfere with potential high-powered acquisitions, a goal many
startups work towards to, and may be something that Microsoft
does not need to bother with.  So in theory they might even have
improved.  I'd need to check again.

I haven’t delved into this either, but I know that they “support
GPL” (whatever that means).

But LilyPond is a size where taking out a commercial offer would
be pretty expensive, and taking out a free offer means you have
nothing to rely or insist on since there hasn't been an exchange
of considerations involved.

True. But, there are GitHub alternatives that are free, for example
Gitea.

Erlend

-- 
David Kastrup

Re: github mirror of lilypond?

[Urs Liska]

Am Sonntag, den 19.01.2020, 20:31 + schrieb Erlend Aasland:
> True. But, there are GitHub alternatives that are free, for example
> Gitea.

Yes, but self-hosting a Git repository software (well, I have a Gitea
instance on my server) is an involved thing, and I don't think it's
reasonable to expect putting that burden and responsibility on
someone's personal shoulders.
I don't think that's an option for us either, although it would be the
way to go on a conceptual level. We'd have some money to pay for the
server and the maintenance...

Urs

Re: github mirror of lilypond?

[Erlend Aasland]

(Sorry for the messed up indent/quote level. Apple Mail is a pain in the butt 
sometimes.)

> On 19 Jan 2020, at 21:31, Erlend Aasland  wrote:
> 
> On 19 Jan 2020, at 18:19, David Kastrup mailto:d...@gnu.org>> 
> wrote:
> What is of concern is the whole metadata about issues and their handling
> and resolution, the stuff you propose moving to GitHub in the first
> place.
> 
> Just for the record; I’m not suggesting GitHub as the one and only 
> alternative. I think I mentioned some of the GH alternatives in my original 
> email, IIRC.
> 
> I understand the concern about metadata and such, but a lot of that 
> information is already present in the commits (both as metadata in the 
> commits and as commit messages), so I guess you’ve already put uncomfortably 
> much information in there already…
> 
> The current use of Savannah hosting for that reason is not a whole lot
> more than a vote of confidence to GNU/FSF/Stallman (which at the current
> point of time are more separate entities than they historically were)
> but not of practical importance.
> 
> True.
> 
> Our current ties to Google (via Rietveld) and SourceForge (for
> Allura/issue tracking) are practically speaking more tenuous to replace.
> Of course they deserve replacing, but doing so by picking GitHub would
> definitely be a much more invasive step for the project than just
> entertaining a Git mirror.
> 
> True.
> 
> Make no mistake: our current dependencies in that regard are of lukewarm
> quality concerning the "Free Software" regard and are a crutch
> technically.  So a change is definitely called for.
> 
> True.
> 
> But I don’t consider GitHub a nobrainer or I'd likely have an account there: 
> I chose
> not to the last time I read their terms of use, and while I haven't
> rechecked since then, its change of ownership does not inspire
> confidence.  Now of course the terms and guarantees then might have been
> chosen in order not to interfere with potential high-powered
> acquisitions, a goal many startups work towards to, and may be something
> that Microsoft does not need to bother with.  So in theory they might
> even have improved.  I'd need to check again.
> 
> I haven’t delved into this either, but I know that they “support GPL” 
> (whatever that means).
> 
> But LilyPond is a size where taking out a commercial offer would be pretty 
> expensive, and
> taking out a free offer means you have nothing to rely or insist on
> since there hasn't been an exchange of considerations involved.
> 
> True. But, there are GitHub alternatives that are free, for example Gitea.
> 
> 
> Erlend
> 
> 
> --
> David Kastrup
> 

Re: github mirror of lilypond?

[Erlend Aasland]

On 19 Jan 2020, at 18:19, David Kastrup mailto:d...@gnu.org>> 
wrote:
What is of concern is the whole metadata about issues and their handling
and resolution, the stuff you propose moving to GitHub in the first
place.

Just for the record; I’m not suggesting GitHub as the one and only alternative. 
I think I mentioned some of the GH alternatives in my original email, IIRC.

I understand the concern about metadata and such, but a lot of that information 
is already present in the commits (both as metadata in the commits and as 
commit messages), so I guess you’ve already put uncomfortably much information 
in there already…

The current use of Savannah hosting for that reason is not a whole lot
more than a vote of confidence to GNU/FSF/Stallman (which at the current
point of time are more separate entities than they historically were)
but not of practical importance.

True.

Our current ties to Google (via Rietveld) and SourceForge (for
Allura/issue tracking) are practically speaking more tenuous to replace.
Of course they deserve replacing, but doing so by picking GitHub would
definitely be a much more invasive step for the project than just
entertaining a Git mirror.

True.

Make no mistake: our current dependencies in that regard are of lukewarm
quality concerning the "Free Software" regard and are a crutch
technically.  So a change is definitely called for.

True.

But I don’t consider GitHub a nobrainer or I'd likely have an account there: I 
chose
not to the last time I read their terms of use, and while I haven't
rechecked since then, its change of ownership does not inspire
confidence.  Now of course the terms and guarantees then might have been
chosen in order not to interfere with potential high-powered
acquisitions, a goal many startups work towards to, and may be something
that Microsoft does not need to bother with.  So in theory they might
even have improved.  I'd need to check again.

I haven’t delved into this either, but I know that they “support GPL” (whatever 
that means).

But LilyPond is a size where taking out a commercial offer would be pretty 
expensive, and
taking out a free offer means you have nothing to rely or insist on
since there hasn't been an exchange of considerations involved.

True. But, there are GitHub alternatives that are free, for example Gitea.


Erlend


--
David Kastrup

Re: github mirror of lilypond?

[pkx166h]

On 19/01/2020 07:41, Han-Wen Nienhuys wrote:
>
> I don't how this done today with LilyPond (manually?). Doing this
> manually is tedious and error-prone busywork. 

Thanks for the compliment Han-wen.

Much appreciated.

regards

James 'the error-prone busy-worker'.

Re: github mirror of lilypond?

[David Kastrup]

Erlend Aasland  writes:

>> On 19 Jan 2020, at 00:00, David Kastrup  wrote:
>> 
>> Erlend Aasland  writes:
>> 
>> GitHub is putting our eggs in Microsoft's basket.  Not too enthused
>> about that idea.
>
> Technically, you already did, since there is a GitHub LilyPond mirror…

Disagree.  The repository is of actually little concern: there are a
gazillion private copies and there are enough hosting services offering
a Git repository that one more or less does not really make a
difference.

What is of concern is the whole metadata about issues and their handling
and resolution, the stuff you propose moving to GitHub in the first
place.

The current use of Savannah hosting for that reason is not a whole lot
more than a vote of confidence to GNU/FSF/Stallman (which at the current
point of time are more separate entities than they historically were)
but not of practical importance.

Our current ties to Google (via Rietveld) and SourceForge (for
Allura/issue tracking) are practically speaking more tenuous to replace.
Of course they deserve replacing, but doing so by picking GitHub would
definitely be a much more invasive step for the project than just
entertaining a Git mirror.

Make no mistake: our current dependencies in that regard are of lukewarm
quality concerning the "Free Software" regard and are a crutch
technically.  So a change is definitely called for.  But I don't
consider GitHub a nobrainer or I'd likely have an account there: I chose
not to the last time I read their terms of use, and while I haven't
rechecked since then, its change of ownership does not inspire
confidence.  Now of course the terms and guarantees then might have been
chosen in order not to interfere with potential high-powered
acquisitions, a goal many startups work towards to, and may be something
that Microsoft does not need to bother with.  So in theory they might
even have improved.  I'd need to check again.  But LilyPond is a size
where taking out a commercial offer would be pretty expensive, and
taking out a free offer means you have nothing to rely or insist on
since there hasn't been an exchange of considerations involved.

-- 
David Kastrup

Re: github mirror of lilypond?

[Jonas Hahnfeld via Discussions on LilyPond development]

General things first: The UI of Gerrit v3 seems to be much nicer than
its previous version. Back then I found it incredibly hard to just look
at the diff. I just made another attempt for a random change from 
https://gerrit.wikimedia.org/ - does it really try to open a new tab
for each file if I click "Open All"? After managing to get into the
diff view, do I really need to navigate through the files one by one?
Preferably I'd like the diff of all files on one page, Rietveld at
least gives me the possibility to "Jump to" a named file.

With Gerit v3, I get an obvious "expand all" - wow.

Am Sonntag, den 19.01.2020, 08:50 +0100 schrieb Han-Wen Nienhuys:
> You can think of Gerrit as Rietveld v2
> 
> This somewhat off-topic, but the main reason people dislike Gerrit is
> that it requires contributors to put a Change-Id line in the bottom of
> the commit message, see eg.
> 
>   
> https://review.gerrithub.io/c/lilypond/lilypond/+/482034
> 
> 
> As one reworks the series of commits, the ChangeId is kept in place.
> This has the advantage that you can track how a proposed change
> evolves across the review process, and that you can easily submit
> multi-part changes for review.

That doesn't really bother me: As far as I understand that's as easy as
properly setting up a local commit hook.

> In the above, I sent a stack of 7
> commits for review at once.

That's where "Relation chain" and "Submitted together" come into play,
right? Funnily enough, "Submitted together" only shows predecessors...

From a high level, I think Gerrit expects reviewers to accept each
change individually. Does this really model the development style of
LilyPond? Being relatively new, I got the perception that we usually
split up a change into logically grouped commits. Eventually I want
them to be viewed and submitted as one push, not one by one as the
individual commits are accepted.
In that regard I really like how Pull Requests / Merge Requests in
GitHub / GitLab / gitea work: You can look at commit granularity if you
want to, but in the end you accept the whole thing. That's also good
because changes to a predecessor might require reworking later patches.

> Working with a single commit requires using commit --amend and with
> multiple commits requires using rebase -i, both of which Git newbies
> seems a little scared of.

Right, but as most other tools you can probably just upload and update
a patch file somewhere? That would be the easiest solution for new
contributors.

Jonas

> 
> On Sun, Jan 19, 2020 at 4:34 AM Karlin High <
> karlinh...@gmail.com
> > wrote:
> > On 1/18/2020 4:59 AM, Jonas Hahnfeld via Discussions on LilyPond
> > development wrote:
> > > I strongly dislike Gerrit, it's really hard to learn and even after
> > > some time I still can't figure out how to use it correctly.
> > 
> > This topic is outside my expertise. But I understood that Gerrit and
> > Rietveld are both descendants of Google's proprietary internal-use
> > Mondrian code review tool.
> > 
> > <
> > https://www.gerritcodereview.com/about.html
> > >
> > 
> > I see quite a few patches lately that show Jonas Hahnfeld as the author...
> > 
> > <
> > https://codereview.appspot.com/user/hahnjo
> > >
> > <
> > https://git.savannah.gnu.org/cgit/lilypond.git/log/?qt=author=Jonas+Hahnfeld
> > >
> > 
> > ...so I'm wondering if Rietveld has you suffering in silence ;) or if
> > the fork and rewrite mentioned on that Gerrit "about" page has greatly
> > diverged the user experiences of these respective products?
> > --
> > Karlin High
> > Missouri, USA
> 
> 
> 
> 


signature.asc
Description: This is a digitally signed message part

Re: github mirror of lilypond?

[Erlend Aasland]

> On 19 Jan 2020, at 00:00, David Kastrup  wrote:
> 
> Erlend Aasland  writes:
> 
> GitHub is putting our eggs in Microsoft's basket.  Not too enthused
> about that idea.

Technically, you already did, since there is a GitHub LilyPond mirror…


E

> If I remember correctly, GitLab had some size
> restrictions that clearly are not going to fly with LilyPond.
> 
> -- 
> David Kastrup

Re: github mirror of lilypond?

[Erlend Aasland]

> On 19 Jan 2020, at 08:41, Han-Wen Nienhuys  wrote:
> 
> On Sun, Jan 19, 2020 at 7:21 AM Werner LEMBERG  wrote:
>>> As it stands, GitLab would probably be a more viable candidate to
>>> look at than GitHub.
>> 
>> I agree.  IMHO, the main repository should stay at Savannah, though.
> 
> I strongly disagree with this.

I do too.

> If we are serious about code review (and it seems that we are), the
> code review has to be integrated with the git hosting system. With the
> current setup, there needs to be infrastructure that takes a patch for
> review, applies it to source tree, runs tests, and then reports back.
> On submission, something has to apply the patch, and push the result
> to the git master branch.

Yes!

E

> I don't how this done today with LilyPond (manually?). Doing this
> manually is tedious and error-prone busywork. If it is automated, it
> requires infrastructure that needs maintenance, and we have too few
> developers anyway.
> 
> Also, in practice, if you visit the lilypond website, or its savannah
> page, one cannot find the in-progress patches that others are working
> on and you cannot find its bug reports.  By contrast, with Gerrit or
> Github, you could go to
> 
>  https://review.gerrithub.io/q/project:lilypond%252Flilypond+status:open
> 
> or
> 
> https://github.com/lilypond/lilypond/pulls
> 
> and see what is happening with the project.
> 
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
> 

Re: github mirror of lilypond?

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Samstag, den 18.01.2020, 21:34 -0600 schrieb Karlin High:
> On 1/18/2020 4:59 AM, Jonas Hahnfeld via Discussions on LilyPond 
> development wrote:
> > I strongly dislike Gerrit, it's really hard to learn and even after
> > some time I still can't figure out how to use it correctly.
> 
> This topic is outside my expertise. But I understood that Gerrit and 
> Rietveld are both descendants of Google's proprietary internal-use 
> Mondrian code review tool.
> 
> <
> https://www.gerritcodereview.com/about.html
> >
> 
> I see quite a few patches lately that show Jonas Hahnfeld as the author...
> 
> <
> https://codereview.appspot.com/user/hahnjo
> >
> <
> https://git.savannah.gnu.org/cgit/lilypond.git/log/?qt=author=Jonas+Hahnfeld
> >
> 
> ...so I'm wondering if Rietveld has you suffering in silence ;) or if 
> the fork and rewrite mentioned on that Gerrit "about" page has greatly 
> diverged the user experiences of these respective products?

Not sure what you're referring to here?
Having tried to work with Gerrit in the past, I found Rietveld easy
enough to use immediately. I'm not saying that it's the best review
tool I've ever used, but relying on SF for issue management is strictly
worse. And that's something that would not be tackled by switching to
Gerrit.

If there are enough people who prefer Gerrit, I'm open to giving it
another try. But if we can get a source hosting that combines all of
git, issues and patch handling, that would simplify things.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: github mirror of lilypond?

[Han-Wen Nienhuys]

You can think of Gerrit as Rietveld v2

This somewhat off-topic, but the main reason people dislike Gerrit is
that it requires contributors to put a Change-Id line in the bottom of
the commit message, see eg.

  https://review.gerrithub.io/c/lilypond/lilypond/+/482034

As one reworks the series of commits, the ChangeId is kept in place.
This has the advantage that you can track how a proposed change
evolves across the review process, and that you can easily submit
multi-part changes for review. In the above, I sent a stack of 7
commits for review at once.

Working with a single commit requires using commit --amend and with
multiple commits requires using rebase -i, both of which Git newbies
seems a little scared of.

On Sun, Jan 19, 2020 at 4:34 AM Karlin High  wrote:
>
> On 1/18/2020 4:59 AM, Jonas Hahnfeld via Discussions on LilyPond
> development wrote:
> > I strongly dislike Gerrit, it's really hard to learn and even after
> > some time I still can't figure out how to use it correctly.
>
> This topic is outside my expertise. But I understood that Gerrit and
> Rietveld are both descendants of Google's proprietary internal-use
> Mondrian code review tool.
>
> 
>
> I see quite a few patches lately that show Jonas Hahnfeld as the author...
>
> 
> 
>
> ...so I'm wondering if Rietveld has you suffering in silence ;) or if
> the fork and rewrite mentioned on that Gerrit "about" page has greatly
> diverged the user experiences of these respective products?
> --
> Karlin High
> Missouri, USA



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: github mirror of lilypond?

[Han-Wen Nienhuys]

On Sun, Jan 19, 2020 at 7:21 AM Werner LEMBERG  wrote:
> > As it stands, GitLab would probably be a more viable candidate to
> > look at than GitHub.
>
> I agree.  IMHO, the main repository should stay at Savannah, though.

I strongly disagree with this.

If we are serious about code review (and it seems that we are), the
code review has to be integrated with the git hosting system. With the
current setup, there needs to be infrastructure that takes a patch for
review, applies it to source tree, runs tests, and then reports back.
On submission, something has to apply the patch, and push the result
to the git master branch.

I don't how this done today with LilyPond (manually?). Doing this
manually is tedious and error-prone busywork. If it is automated, it
requires infrastructure that needs maintenance, and we have too few
developers anyway.

Also, in practice, if you visit the lilypond website, or its savannah
page, one cannot find the in-progress patches that others are working
on and you cannot find its bug reports.  By contrast, with Gerrit or
Github, you could go to

  https://review.gerrithub.io/q/project:lilypond%252Flilypond+status:open

or

 https://github.com/lilypond/lilypond/pulls

and see what is happening with the project.

--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: github mirror of lilypond?

[Urs Liska]

Am Sonntag, den 19.01.2020, 07:20 +0100 schrieb Werner LEMBERG:
> > While that may be true, there are already GNU projects using GitHub
> > as their host, for example gnucash and gnuradio.
> 
> Gnucash uses github as a mirror only, see
> 
>   https://wiki.gnucash.org/wiki/Git#code.gnucash.org
> 
> But gnuradio admittedly uses github.  I'm 100% sure that if RMS knew
> that he would ask them immediately to move the source to a host that
> is more GNU-compliant.
> 
> However, there is nothing bad with mirroring at github, so it's OK if
> LilyPond does the same.

Considering the start of this thread I think there should be some
automatic way of keeping such a mirror up-to-date. It has happened more
than once that people came to think this *is* the code base and try to
patch it.

> 
> > As it stands, GitLab would probably be a more viable candidate to
> > look at than GitHub.
> 
> I agree.  IMHO, the main repository should stay at Savannah, though.

One consideration that hasn't been mentioned this time is that GitHub's
terms of service allow them to discontinue support for a given project
for any reason without notice.

However, I also count to the group of people who would strongly prefer
a more convenient and more welcoming way of contributing. Not in terms
of the review process. While having run into that wall more than once I
agree that it's important to have that tedious kind of process. 
The main advantage of Github and its clones (Gitlab, Gitea) I see over
the current process is a) that the code review is done on the actual
code, if you will, and integrated with the comments, and b) that when a
patch is accepted it can be simply merged (or squashed with/without
merge commit). I'm always feeling insecure when basically redoing my
patch before pushing to staging.

Urs

> 
> 
> Werner
> 

Re: github mirror of lilypond?

[Werner LEMBERG]

> While that may be true, there are already GNU projects using GitHub
> as their host, for example gnucash and gnuradio.

Gnucash uses github as a mirror only, see

  https://wiki.gnucash.org/wiki/Git#code.gnucash.org

But gnuradio admittedly uses github.  I'm 100% sure that if RMS knew
that he would ask them immediately to move the source to a host that
is more GNU-compliant.

However, there is nothing bad with mirroring at github, so it's OK if
LilyPond does the same.

> As it stands, GitLab would probably be a more viable candidate to
> look at than GitHub.

I agree.  IMHO, the main repository should stay at Savannah, though.


Werner

Re: github mirror of lilypond?

[Karlin High]

On 1/18/2020 4:59 AM, Jonas Hahnfeld via Discussions on LilyPond 
development wrote:

I strongly dislike Gerrit, it's really hard to learn and even after
some time I still can't figure out how to use it correctly.


This topic is outside my expertise. But I understood that Gerrit and 
Rietveld are both descendants of Google's proprietary internal-use 
Mondrian code review tool.




I see quite a few patches lately that show Jonas Hahnfeld as the author...




...so I'm wondering if Rietveld has you suffering in silence ;) or if 
the fork and rewrite mentioned on that Gerrit "about" page has greatly 
diverged the user experiences of these respective products?

--
Karlin High
Missouri, USA

Re: github mirror of lilypond?

[Karlin High]

There was a thread from April 2018 that explored GitLab's suitability
for LilyPond.



As I recall from that discussion, most of the first-to-mind concerns
about available features and workflows seemed like things GitLab could
handle.

And pace the FSF, GitLab now has License Compliance features of some sort.

-- 
Karlin High
Missouri, USA

Re: github mirror of lilypond?

[David Kastrup]

Jahrme Risner  writes:

> On 2020-01-08 at 15:00, David Kastrup d...@gnu.org wrote:
>
>> GitHub is putting our eggs in Microsoft's basket. Not too enthused about that
>> idea. If I remember correctly, GitLab had some size restrictions that clearly
>> are not going to fly with LilyPond.
>
> I am not aware of what size limits LilyPond could be running into on GitLab
> given that the repository size limit for repositories hosted on gitlab.com is
> 10G [0]. If there is some other dimension on which LilyPond has exceeded what
> is allowed by GitLab I would be both surprised and interested.



>
> [0]
> https://docs.gitlab.com/ee/user/project/repository/#project-and-repository-size

Current offerings appear to be
https://about.gitlab.com/pricing/

I am pretty sure I heard/read something recently that did not sound
overly great.  Sorry, that's really vague.  I don't quite remember the
details.

-- 
David Kastrup

Re: github mirror of lilypond?

[Jahrme Risner]

On 2020-01-08 at 15:00, David Kastrup d...@gnu.org wrote:

> GitHub is putting our eggs in Microsoft's basket. Not too enthused about that
> idea. If I remember correctly, GitLab had some size restrictions that clearly
> are not going to fly with LilyPond.

I am not aware of what size limits LilyPond could be running into on GitLab
given that the repository size limit for repositories hosted on gitlab.com is
10G [0]. If there is some other dimension on which LilyPond has exceeded what
is allowed by GitLab I would be both surprised and interested.

[0] 
https://docs.gitlab.com/ee/user/project/repository/#project-and-repository-size

On 2020-01-08 at 15:11, Karlin High karlinh...@gmail.com wrote:

> Apparently GNU has some say as well in the matter of repo hosting choice.
> https://www.gnu.org/software/repo-criteria.html
> They also have a report card for various repo hosting services, but it's 
> dated to 2016.
> https://www.gnu.org/software/repo-criteria-evaluation.html

While that may be true, there are already GNU projects using GitHub as their
host, for example gnucash and gnuradio. While that is not a reason LilyPond to
use GitHub (despite its F rating on the GNU repo criteria evaluation), it is
simply an observation that if GitHub was chosen as a new host there would be
some precedent.

According to the report card GitLab would be allowed (it was rated at a C). As
far as finding a host with the "A" rating that Savannah has, I doubt we could
find one that provides the breadth of tooling that GitHub or GitLab provide
given that a requirement for an A rating is that the host must "[insist] that
each nontrivial file in a package clearly and unambiguously state how it is
licensed."

Beyond this kind of requirement being difficult to enforce in practice, the
user base of either GitHub or GitLab would be outraged if this became a
requirement to use the service given how often they are used for ephemeral code
sharing and non-production hosting (e.g., students using private repositories
to store class assignments).

Given that, if discussion about choosing a new host were to commence I think
that achieving an A on the GNU evaluation should not be a requirement for
choosing the host while achieving a C rating must be a requirement, with a B or
higher preferred. I would also hope that in that situation we could get an
updated evaluation of the options by the FSF/GNU.

As it stands, GitLab would probably be a more viable candidate to look at than
GitHub. Further, using something like GitLab does not preclude keeping the
Savannah repository as the "canonical" host. Instead it could replace the
combination of SourceForge (which got an F rating as a code host) and Rietveld.

Jahrme

Re: github mirror of lilypond?

[Karlin High]

On 1/18/2020 5:00 PM, David Kastrup wrote:

GitHub is putting our eggs in Microsoft's basket.  Not too enthused
about that idea.


Apparently GNU has some say as well in the matter of repo hosting choice.



They also have a report card for various repo hosting services, but it's 
dated to 2016.



--
Karlin High
Missouri, USA

Re: github mirror of lilypond?

[David Kastrup]

Erlend Aasland  writes:

> Yes, I’m open for both GitHub, GitLab, Gitea, and similar «complete
> development environments» (or whatever it’s called.) I’ve been working
> in GitHub the last years, and it’s so nice to have a decent
> bugtracker, a great review tool, a great git web interface, and more,
> all in one place. It really saves development time and gets rid of a
> lot of developer frustrations.

GitHub is putting our eggs in Microsoft's basket.  Not too enthused
about that idea.  If I remember correctly, GitLab had some size
restrictions that clearly are not going to fly with LilyPond.

-- 
David Kastrup

Re: github mirror of lilypond?

[Erlend Aasland]

Yes, I’m open for both GitHub, GitLab, Gitea, and similar «complete development 
environments» (or whatever it’s called.) I’ve been working in GitHub the last 
years, and it’s so nice to have a decent bugtracker, a great review tool, a 
great git web interface, and more, all in one place. It really saves 
development time and gets rid of a lot of developer frustrations.
Erlend


From: Jonas Hahnfeld 
Sent: Saturday, January 18, 2020 11:59:37 AM
To: Han-Wen Nienhuys ; Erlend Aasland 
Cc: lilypond-devel 
Subject: Re: github mirror of lilypond?

Am Samstag, den 18.01.2020, 10:38 +0100 schrieb Han-Wen Nienhuys:
> On Sat, Jan 18, 2020 at 8:35 AM Erlend Aasland <
> erlen...@innova.no
> > wrote:
> > Is there a reason _not_ to use GitHub for 
> > development/bugtracking/wiki/planning? The current dev model is, to put it 
> > mildly, and in lack of better words, cumbersome and archaic. GNU licences 
> > are AFAICS supported by GitHub, so that can’t be a showstopper. If we had a 
> > more modern development model, it would perhaps be easier to engage new 
> > (and old) developers. No offence meant for those of you who like the 
> > current dev model!
>
> I think this would be a good thing to discuss at the Salzburg event.
>
> I am partial to Gerrit, see eg.
>
>
> https://review.gerrithub.io/q/lilypond/lilypond
>
>
> regardless of the particular choice, though, a more standard
> environment would save developer time, and make it easier to onboard
> contributors.

I strongly dislike Gerrit, it's really hard to learn and even after
some time I still can't figure out how to use it correctly.
Both GitHub and GitLab (on gitlab.com) would be a great improvement.
Not sure though if this is "allowed" for GNU projects (it's probably
not about the license, but being "GNU LilyPond").

Jonas

Re: github mirror of lilypond?

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Samstag, den 18.01.2020, 10:38 +0100 schrieb Han-Wen Nienhuys:
> On Sat, Jan 18, 2020 at 8:35 AM Erlend Aasland <
> erlen...@innova.no
> > wrote:
> > Is there a reason _not_ to use GitHub for 
> > development/bugtracking/wiki/planning? The current dev model is, to put it 
> > mildly, and in lack of better words, cumbersome and archaic. GNU licences 
> > are AFAICS supported by GitHub, so that can’t be a showstopper. If we had a 
> > more modern development model, it would perhaps be easier to engage new 
> > (and old) developers. No offence meant for those of you who like the 
> > current dev model!
> 
> I think this would be a good thing to discuss at the Salzburg event.
> 
> I am partial to Gerrit, see eg.
> 
>   
> https://review.gerrithub.io/q/lilypond/lilypond
> 
> 
> regardless of the particular choice, though, a more standard
> environment would save developer time, and make it easier to onboard
> contributors.

I strongly dislike Gerrit, it's really hard to learn and even after
some time I still can't figure out how to use it correctly.
Both GitHub and GitLab (on gitlab.com) would be a great improvement.
Not sure though if this is "allowed" for GNU projects (it's probably
not about the license, but being "GNU LilyPond").

Jonas


signature.asc
Description: This is a digitally signed message part

Re: github mirror of lilypond?

[Han-Wen Nienhuys]

On Sat, Jan 18, 2020 at 8:35 AM Erlend Aasland  wrote:
>
> Is there a reason _not_ to use GitHub for 
> development/bugtracking/wiki/planning? The current dev model is, to put it 
> mildly, and in lack of better words, cumbersome and archaic. GNU licences are 
> AFAICS supported by GitHub, so that can’t be a showstopper. If we had a more 
> modern development model, it would perhaps be easier to engage new (and old) 
> developers. No offence meant for those of you who like the current dev model!

I think this would be a good thing to discuss at the Salzburg event.

I am partial to Gerrit, see eg.

  https://review.gerrithub.io/q/lilypond/lilypond

regardless of the particular choice, though, a more standard
environment would save developer time, and make it easier to onboard
contributors.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: github mirror of lilypond?

[Han-Wen Nienhuys]

Aha! I am in the group that controls this :-)

I pushed it up to current master.

On Sat, Jan 18, 2020 at 12:04 AM Han-Wen Nienhuys  wrote:
>
> It looks like https://github.com/lilypond was last updated in Jun
> 2019. If there was an automated mirror, it has stopped working. Could
> someone give it a kick again?
>
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: github mirror of lilypond?

[Erlend Aasland]

Is there a reason _not_ to use GitHub for 
development/bugtracking/wiki/planning? The current dev model is, to put it 
mildly, and in lack of better words, cumbersome and archaic. GNU licences are 
AFAICS supported by GitHub, so that can’t be a showstopper. If we had a more 
modern development model, it would perhaps be easier to engage new (and old) 
developers. No offence meant for those of you who like the current dev model!


Erlend



From: lilypond-devel  
on behalf of Han-Wen Nienhuys 
Sent: Saturday, January 18, 2020 12:04:15 AM
To: lilypond-devel 
Subject: github mirror of lilypond?

It looks like https://github.com/lilypond was last updated in Jun
2019. If there was an automated mirror, it has stopped working. Could
someone give it a kick again?

--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

github mirror of lilypond?

[Han-Wen Nienhuys]

It looks like https://github.com/lilypond was last updated in Jun
2019. If there was an automated mirror, it has stopped working. Could
someone give it a kick again?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen