Re: improving our workflow with better tools - let's test things.

[Joseph Rushton Wakeling]

On 21/10/13 07:58, Werner LEMBERG wrote:

I don't see a major simplification for the maintainer.  The most
important action IMHO for contributing a patch is to rebase, ensuring
that the patch compiles with master.  As far as I can see, github's
ticketing system doesn't allow to simply update the patch; instead,
you have to open a new ticket.


Not true at all.  Rebase your branch, then,

git push -f origin my-branch

... will overwrite the contents of the pull request branch, and so update the 
request itself.  I've done it many times. :-)


Hopefully GitLab allows for similar functionality -- I will be checking this.


Lilypond's two-level approach with
separating issues from actual patches gives more consistency here.
Please correct me if I'm wrong.


GitHub has separate issues and pull requests, but there's automated coordination 
between the two -- so submit a pull request titled "Fix Issue #102" (or with a 
reference to Issue #102 in the description) the issue tracker will pick up on 
the fact that such-and-such a pull request has referenced that issue; and 
vice-versa if in an issue, I make reference to a commit or pull request.


As Carl noted, GitLab doesn't have that automated relationship yet, but it 
should be arriving in the next release.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Werner LEMBERG]

>> As far as I can see, github's ticketing system doesn't allow to
>> simply update the patch; instead, you have to open a new ticket.
> 
> Not true at all.  Rebase your branch, then,
> 
> git push -f origin my-branch
> 
> ... will overwrite the contents of the pull request branch, and so
> update the request itself.  I've done it many times. :-)

Good to know, thanks.  [I assume that `overwrite' still somehow
retains the previously version for reference, right?]


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Joseph Rushton Wakeling]

On 21/10/13 09:09, Werner LEMBERG wrote:

Good to know, thanks.  [I assume that `overwrite' still somehow
retains the previously version for reference, right?]


In the short term I think so (you'll see stuff in the comment history like 
"so-and-so commented on an outdated diff").  In the long run it seems to be 
discarded.  You may recall that git periodically collects garbage from the 
version history, but on a time frame so that even "deleted" material is 
preserved for at least 1 month -- see:

https://www.kernel.org/pub/software/scm/git/docs/git-gc.html

So I'm guessing that GitHub preserves this data until git collects the garbage 
from the repo.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Joseph Rushton Wakeling]

A couple of messages accidentally went off-list, forwarding them back here with 
Werner's agreement :-)


On 21/10/13 08:02, Werner LEMBERG wrote:



The other advantage is that the merge commit is "authored" by the
person with master commit access who approves the merge request.
So, you have in history not just who wrote what, but also who took
the decision to include it.  That can be valuable.


Hmm.  In case this is important, you have to GPG-sign patches,
possible since git version 1.7.9.  I think that lilypond doesn't
belong into the category of programs where this is necessary.


Yes, GPG-signed patches can be used to track authorization, approval etc., but 
as you say, it's overkill for something like Lilypond.  I'm just talking instead 
about having an easily visible record of "Who reviewed/approved this?".


It's surely a matter of taste, but personally on a large-ish project with lots 
of contributors, I find the "only merge commits in the master branch" approach 
to be quite useful as a way of keeping a clean overview of changes to the 
codebase, with the option to drill deeper if necessary.



You might read

   http://mikegerwitz.com/papers/git-horror-story.html

on this topic.


Thanks for that -- had not come across it before.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Trevor Daniels]

Joseph Rushton Wakeling wrote Monday, October 21, 2013 6:50 AM

> On 21/10/13 06:13, Carl Sorensen wrote:

>> What me drives crazy is the structure of the main git repository.  If
>> you follow github style, the graph gets littered with zillions of
>> `merge request' commits, one per pull request, which makes it quite
>> hard to follow the development IMHO.

> It's true it can get annoying if you have lots of one-commit contributions.  
> On 
> the other hand it lends itself to being able to split your contributions into 
> multiple separate commits for which the main git history simply gets a 
> summary 
> (the merge commit).
> 
> I still think it's ultimately worth it for the discipline of "No one pushes 
> directly to master", which helps enforce a requirement that everything gets 
> tested and reviewed, even stuff by core developers.

The vast majority of my contributions are single-commit, and I
suspect most other contributions are the same.  They are easy
to manage and generate a clean history with merge commits 
appearing only when they are appropriate.  Our git repository was
not always managed in this way, so the advantages of a clean history 
are obvious, at least to me.

Our current workflow already enforces: "No one pushes directly to master".  
Why is it "ultimately worth it" to lose a real advantage only to regain 
something we already have?

Having worked with Carl for some years I respect his opinion,
and for me his bottom line: "I'm seriously thinking of junking
Gitlab because the benefit seems to be more promised than realized",
based on his experience of actually using Gitlab on a real project 
clinches the matter.

Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Joseph Rushton Wakeling]

On 21/10/13 10:01, Trevor Daniels wrote:

The vast majority of my contributions are single-commit, and I
suspect most other contributions are the same.  They are easy
to manage and generate a clean history with merge commits
appearing only when they are appropriate.  Our git repository was
not always managed in this way, so the advantages of a clean history
are obvious, at least to me.


I wouldn't want to do anything to disrupt having a clean git history.


Our current workflow already enforces: "No one pushes directly to master".
Why is it "ultimately worth it" to lose a real advantage only to regain
something we already have?


It's not just about "no one pushes ..." but also about having, in the version 
history, a visible log of both who authored code and who approved its inclusion. 
 I don't think the result is fundamentally less "clean" than the alternative of 
single-commits-plus-merges-when-necessary; what you actually ought to see is a 
linear history of one-merge-commit-per-new-feature.


But I accept it's a matter of taste.


Having worked with Carl for some years I respect his opinion,
and for me his bottom line: "I'm seriously thinking of junking
Gitlab because the benefit seems to be more promised than realized",
based on his experience of actually using Gitlab on a real project
clinches the matter.


Before we risk people getting demotivated, I think we should be clear that at 
this stage it's unlikely that the advantages of any alternative will be obvious. 
 If they were obvious, all of you would be leaping and jumping to get things 
set up this way and Janek, Colin and I wouldn't be having to do this exploratory 
work!


The onus is clearly on us to make the case to you -- I'd simply like to ask that 
you all keep an open mind while we explore the possibilities.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[David Kastrup]

"Trevor Daniels"  writes:

> Our current workflow already enforces: "No one pushes directly to
> master".

There is no actual enforcement by technical means.  Our enforcement
basically is peer pressure and habit/discipline.  That allows for
emergency repair actions.  And of course it allows for people running
Patchy without requiring special access.

> Why is it "ultimately worth it" to lose a real advantage only to regain 
> something we already have?
>
> Having worked with Carl for some years I respect his opinion,
> and for me his bottom line: "I'm seriously thinking of junking
> Gitlab because the benefit seems to be more promised than realized",
> based on his experience of actually using Gitlab on a real project 
> clinches the matter.

Depends on whether the circumstances are comparable.  Our
development/review tools for LilyPond have evolved with the aim to
integrate work of non-programmers into our workflows.  Most projects are
more homogeneous in the function and capabilities of its members than
LilyPond is.

Now it's rather hard to do a proper balance of the merits: basically we
are not aiming for a "I could discipline myself into using xxx" verdict
but rather for "this will definitely make things quite easier for me in
the long run" for a majority of existing and potential contributors.

Now testing a setup is, in a way, sort of an intellectual challenge,
costs energy, and one is understandably proud if one masters such a
challenge and does not want this work to go to waste.

But in the end, of course we are interested most in those experiments
which ended up not challenging at all, at least from the user side.

I'd rather have people try out five tools in a rather shallow fashion
and report back their relative impressions than have five different
people involve themselves deeply with a particular setup.  That way we
lose the focus on "easy for the casual user" and lose the comparison.

So let's not discuss each single option to death in order not to waste
our testers.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Joseph Rushton Wakeling]

On 21/10/13 11:11, David Kastrup wrote:

Now it's rather hard to do a proper balance of the merits: basically we
are not aiming for a "I could discipline myself into using xxx" verdict
but rather for "this will definitely make things quite easier for me in
the long run" for a majority of existing and potential contributors.

Now testing a setup is, in a way, sort of an intellectual challenge,
costs energy, and one is understandably proud if one masters such a
challenge and does not want this work to go to waste.


Well, it depends on the overall outcome.  There's no shame in coming to the 
conclusion "OK, I spent a lot of time mastering that tool and in so doing I 
proved definitively that it doesn't work as well as other stuff I know."


I may be very critical of Lilypond's existing tools, but I'm not going to try 
and push you towards an inadequate development environment just because I spent 
time trying to get it to work.



But in the end, of course we are interested most in those experiments
which ended up not challenging at all, at least from the user side.

I'd rather have people try out five tools in a rather shallow fashion
and report back their relative impressions than have five different
people involve themselves deeply with a particular setup.  That way we
lose the focus on "easy for the casual user" and lose the comparison.


Casual impressions of GitLab: it seems to offer broadly the same scope of 
functionality as GitHub (it's much more feature-complete and user-friendly 
compared to Gitorious).  There are lots of little ways in which it is less 
user-friendly than GitHub; none of them are showstoppers, but any of them would 
be annoying to someone used to GitHub workflows.


One single example: if you rebase and force-push a branch, open merge requests 
won't automatically pick up on the new code; you have to manually edit the merge 
request.  It's two mouse clicks -- click "Edit", click "Save changes" -- but 
that's two mouse clicks you don't need in GitHub.


It's a promising tool but not a perfect one, and it's playing catch-up with the 
state-of-the-art.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Carl Sorensen]

On 10/21/13 2:01 AM, "Trevor Daniels"  wrote:

>
>Having worked with Carl for some years I respect his opinion,
>and for me his bottom line: "I'm seriously thinking of junking
>Gitlab because the benefit seems to be more promised than realized",
>based on his experience of actually using Gitlab on a real project
>clinches the matter.

Thanks for the kind words, Trevor.  But I think you may be reading too
much into my opinion.  I've *experimented* with GitLab on a real project
(I've only put about 3 weeks of work into it), and my project is only 3
developers at one physical site, so we can manage without *any* formal
tool if we need to.  And I *haven't* set up the equivalent of LilyPond's
infrastructure on my project, either.

And based on Joseph's comments, it appears that I may be misusing GitLab a
little bit -- we've not been using good descriptions of the merge requests
(in fact, we may have not been using *any* descriptions of the merge
requests) so the merge commits only have the git-generated statement about
the merge.  I'll try doing a better job on merge request descriptions and
see if I like that better.

I'm used to writing things in git commits, and not having to rewrite them
to push to staging, so having to rewrite for a merge request is something
to get used to, not necessarily something to hate.

Anyway, I think that it's too early to reject the possibility that
different tools could improve the contribution experience.  I'd recommend
that we give the team time to explore the setup of a GitLab workflow
before we make a decision.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Carl Sorensen]

On 10/21/13 1:09 AM, "Werner LEMBERG"  wrote:

>
>>> As far as I can see, github's ticketing system doesn't allow to
>>> simply update the patch; instead, you have to open a new ticket.
>> 
>> Not true at all.  Rebase your branch, then,
>> 
>> git push -f origin my-branch
>> 
>> ... will overwrite the contents of the pull request branch, and so
>> update the request itself.  I've done it many times. :-)
>
>Good to know, thanks.  [I assume that `overwrite' still somehow
>retains the previously version for reference, right?]
Yes.

The merge request is a merge request for a branch, not for a commit.  So
once you have a merge request up, it tracks any changes in that branch.
This has both positive and negative implications in my mind.  It's
positive in that any work I do on the branch is automatically translated
into the merge request.  It's negative in that any unintended changes I
make on the branch automatically get translated into the merge request.

In our current workflow, once I submit a patch, it's a fixed submission.
I have to resubmit a different patch in order to change it.

In the gitlab workflow, when I submit a merge request, it's a dynamic
thing.  Any time I push my merge-request branch to origin, I'm changing
the merge request.  (Oh -- I just saw the protection against unintended
changes -- don't push the branch to origin!)

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Joseph Rushton Wakeling]

On 21/10/13 14:25, Carl Sorensen wrote:

And based on Joseph's comments, it appears that I may be misusing GitLab a
little bit -- we've not been using good descriptions of the merge requests
(in fact, we may have not been using *any* descriptions of the merge
requests) so the merge commits only have the git-generated statement about
the merge.  I'll try doing a better job on merge request descriptions and
see if I like that better.


No, you were right -- it's a current limitation of GitLab, and a very irritating 
one at that.  See:

http://feedback.gitlab.com/forums/176466-general/suggestions/3489764-allowing-custom-commit-message-for-merge-requests

I think one workaround might be to perform the merge manually -- I'll let you 
know how this goes.


GitHub does this in a much nicer way: the merge commit message references the 
pull request ID and includes at least the title of the pull request, so that you 
can always find the associated discussion and have at least an overview of what 
the merge does.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: improving our workflow with better tools - let's test things.

[Joseph Rushton Wakeling]

On 21/10/13 14:30, Carl Sorensen wrote:

In our current workflow, once I submit a patch, it's a fixed submission.
I have to resubmit a different patch in order to change it.

In the gitlab workflow, when I submit a merge request, it's a dynamic
thing.  Any time I push my merge-request branch to origin, I'm changing
the merge request.  (Oh -- I just saw the protection against unintended
changes -- don't push the branch to origin!)


I found the opposite -- that whereas with GitHub any push to the feature branch 
updates the corresponding pull request, with GitLab that _doesn't_ happen; I had 
to manually click on the "Edit" button for GitLab to recognize that the head of 
the branch had changed, and then click "Save Changes" to update it.  But maybe 
this is a cosmetic issue and actually if I approved the merge, it would be the 
branch head that got merged.  I'll test.


On GitHub personally I find this auto-update of the pull request useful.  Apart 
from anything else, if you realize there's some small issue with what you 
submitted, it makes it trivial to fix, and it means you can have a fast 
turnaround between receiving reviewer feedback and responding to it with 
patches.  If you wind up with too many patches in the pull request, you can 
always rebase and squash stuff before the branch is merged.


More broadly, in the GitHub-style workflow (which GitLab is copying) it's a good 
rule of thumb to assume, "Don't push anything to any public branch unless you 
intend for other people to see and use it."


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Remove DynamicText from script-interface (issue 14424044)

[mike]

Make sure to acknowledge dynamic text in slur-proto-engraver.cc and
tuplet-engraver.cc.

https://codereview.appspot.com/14424044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

epic slur fail!

[Janek Warchoł]

Hi,

i'm browsing slur formatting code and i found why slurs in these cases

{
  \slurUp
  d'2( f')
  \slurDown
  c''2( e'')
}

are soo ugly.
I facepalmed really hard :-)

Expect an awesome patch tomorrow.

best,
Janek
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCHES: Countdown – October 25th – 06:00 GMT

[James]

 *Countdown – October 25th – 06:00 GMT* *
* *
* *
* *
*  *
* *
* *
* *
* *
*  
3621
Enhancement
Janek Warchol push Patch: Improve formatting of PaperColumn debug info









 
3625
Enhancement
David Kastrup countdown Patch: Overrides via \tweak don't insist on proper
context/grob and property split
3624
Defect
David Kastrup countdown Patch: make-connected-path-stencil broke on closed
paths  
3623
Scripts
David Kastrup countdown lilypond-book fails with file names containing
shell-special characters
3616
Enhancement
David Kastrup countdown Patch: Give \hide, \omit, \undo more exposure
3458
Documentation
David Nalesnik countdown Add documentation of \alterBroken music function
2392
Crash
David Kastrup countdown Segfault in connection with \applyContext









 
3626
Enhancement
David Kastrup review Patch: Remove unused iv in
Side_position_interface::aligned_side
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: xpdf situation with Ubuntu?

[James]

Hello,

XPDF in Ubuntu 10.04 - my lilydev at home works. version 3.0.2

xpdf in Linux Mint 15 (Olivia) whatever that is the Ubuntu Equiv (it's not
the Debian one) crashes - I think that is 13.04. Version 3.0.3.

James


On 20 October 2013 23:10, David Kastrup  wrote:

>
> Hi,
>
> xpdf in Ubuntu had been unworking for quite a bit of time.  I am
> currently using 13.10 which has been fixed, and I _believe_ that at
> least for 13.04 there is by now a backport in the repositories.  Can
> users of version 13.04 and/or possibly earlier versions report back
> their xpdf situation?
>
> The "old" situation was "crashes when opening any PDF file with it".
> Easy to detect...  Since Xdf is pretty much the easiest viewer to set up
> for point-and-click, it would be good if our manual reflects the current
> state reasonably accurately.
>
> So if people having Ubuntu other than 13.10 installed could check?
> Thanks.
>
> --
> David Kastrup
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: xpdf situation with Ubuntu?

[David Kastrup]

James  writes:

> Hello,
>
> XPDF in Ubuntu 10.04 - my lilydev at home works. version 3.0.2
>
> xpdf in Linux Mint 15 (Olivia) whatever that is the Ubuntu Equiv (it's not
> the Debian one) crashes - I think that is 13.04. Version 3.0.3.

Do you keep it updated?  Do _they_ keep it updated?

Thanks

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel