Re: xpdf situation with Ubuntu?

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

Re: xpdf situation with Ubuntu?

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

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

*Countdown – October 25th – 06:00 GMT* * * * * * * * * * * * * * * * * * * 3621 Enhancement Janek Warchol push Patch: Improve form

epic slur fail!

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 lis

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

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

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

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 or

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

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 ha

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

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 overwr

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

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

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

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

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

"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 peo

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

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 alw

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

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,

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

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 hi

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

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

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

>> 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 > up

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

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 p