Re: we now have "lilypond" organization on GitHub

Jan Nieuwenhuizen writes: > Urs Liska writes: > >> You are doing code reviews through a web interface already, isn't it? >> And this is because that's a quite natural way to communicate, comment >> on code etc. You can't do _that_ with plain Git. > > To me, this is one the most unnatural and ther

Re: we now have "lilypond" organization on GitHub

Am 18.09.2013 09:46, schrieb David Kastrup: Jan Nieuwenhuizen writes: Urs Liska writes: You are doing code reviews through a web interface already, isn't it? And this is because that's a quite natural way to communicate, comment on code etc. You can't do _that_ with plain Git. To me, this i

Re: we now have "lilypond" organization on GitHub

Urs Liska writes: > Am 18.09.2013 09:46, schrieb David Kastrup: > >> Well, it facilitates looking at stuff in context (though that's fairly >> trivial to do by actually applying the patch in a cloned repository, and >> in-file-system clones of git repositories are _really_ cheap). >> >> It's pret

Re: we now have "lilypond" organization on GitHub

2013/9/18 David Kastrup > The one area where I'd consider a web interface a possibly good tradeoff > of matching tools to skills would be translation work: that could/should > be a lot more crowdsourced than it is now. It turns out that organizing > and tracking incremental translation work requ

Re: we now have "lilypond" organization on GitHub

2013/9/17 David Kastrup : > And yet [Linus] wrote Linux instead of using the best available tool for the > job: he already had a copy of Minix, interactive UNIX was quite > affordable, and other cheap versions came around. I'm not sure, but from what i've read it seems that Linus initially wrote L

Re: we now have "lilypond" organization on GitHub

2013/9/18 David Kastrup : > Comparing the amount of code actually getting reviewed and the amount of > development getting done, the Linux kernel does not seem to suffer all > that badly from working with a patch/mail-centric [review] workflow. > > Of course there are some reasons that don't hold f

Re: we now have "lilypond" organization on GitHub

2013/9/18 David Kastrup : > >>> The one area where I'd consider a web interface a possibly good >>> tradeoff of matching tools to skills would be translation work: that >>> could/should be a lot more crowdsourced than it is now. It turns out >>> that organizing and tracking incremental translation

Re: we now have "lilypond" organization on GitHub

Janek Warchoł writes: > 2013/9/18 David Kastrup : >> Comparing the amount of code actually getting reviewed and the amount of >> development getting done, the Linux kernel does not seem to suffer all >> that badly from working with a patch/mail-centric [review] workflow. >> >> Of course there are

Re: we now have "lilypond" organization on GitHub

Janek Warchoł writes: > Just a reminder: nobody's talking about replacing everything with > web-based interfaces. I think that the discussion is about providing > both web-based and other interfaces. > > And i know at least one potential serious contributor that is driven > away by complicated i

Re: we now have "lilypond" organization on GitHub

Urs Liska: > Am 17.09.2013 18:21, schrieb David Kastrup: > > Janek Warchoł writes: > > > >> 2013/9/16 David Kastrup: > >>> So the question is what we should be telling the Savannah operators > >>> to make working on GNU projects using Git more feasible. > >> Here you go: > >> A web interface with

Re: we now have "lilypond" organization on GitHub

k...@aspodata.se (Karl Hammar) writes: > What's natural is different for different people. > > Web interfaces are not natural for me, to the contrary, for me > they appear constrained. The main question is what's natural to those people we can have a reasonable expectation to be working on LilyPo

Re: we now have "lilypond" organization on GitHub

2013/9/17 Urs Liska : > But as far as I've understood, code doesn't get into upstream master that > way anyway, there is the Rietveld code review stage in between? > How do commits (from developers) actually end up in master? > Are they a) pushed to some branch, the diff uploaded to Rietveld, and u

Re: we now have "lilypond" organization on GitHub

2013/9/18 Janek Warchoł : > 2013/9/17 Urs Liska : >> But as far as I've understood, code doesn't get into upstream master that >> way anyway, there is the Rietveld code review stage in between? >> How do commits (from developers) actually end up in master? > > It's > c) they are usually not pushed

Re: we now have "lilypond" organization on GitHub

Am 18.09.2013 14:28, schrieb Janek Warchoł: 2013/9/18 Janek Warchoł : 2013/9/17 Urs Liska : But as far as I've understood, code doesn't get into upstream master that way anyway, there is the Rietveld code review stage in between? How do commits (from developers) actually end up in master? It's

Re: we now have "lilypond" organization on GitHub

Urs Liska writes: > Am 18.09.2013 14:28, schrieb Janek Warchoł: >> 2013/9/18 Janek Warchoł : >>> 2013/9/17 Urs Liska : But as far as I've understood, code doesn't get into upstream master that way anyway, there is the Rietveld code review stage in between? How do commits (from deve

Re: we now have "lilypond" organization on GitHub

2013/9/17 David Kastrup : > Now basically we have to split these into two different sets of > requirements: Savannah does not provide accounts or services to the > general public; its services will be restricted to actual developers. > > But what you list above mostly is _not_ related to participat

Re: we now have "lilypond" organization on GitHub

Janek Warchoł writes: > [..] since the most important thing in my opinion is how contributors > can interact with the main repository. Currently it is, and that's also the next most important concept to drop and move to a distributed workflow, for some of those reasons, see http://psung.blog

Re: Issue 3557: Fix some grammar mistakes. (issue 13373054)

LGTM https://codereview.appspot.com/13373054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Tuplet-bracket: do not crash; issue 3551 (issue 13352053)

LGTM https://codereview.appspot.com/13352053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: we now have "lilypond" organization on GitHub

- Original Message - From: "David Kastrup" To: "Urs Liska" Cc: "Julien Rioux" ; "LilyPond Developmet Team" ; "Han-Wen Nienhuys" Sent: Wednesday, September 18, 2013 1:37 PM Subject: Re: we now have "lilypond" organization on GitHub Urs Liska writes: Am 18.09.2013 14:28, schrieb

Re: we now have "lilypond" organization on GitHub

2013/9/18 Phil Holmes : > - Original Message - From: "David Kastrup" >> Urs Liska writes: >>> When review is finished prepare a patch file (or series of patch >>> files) and find someone with push access whom I can send it to? >> >> Yup. > > Strictly, not necessarily even that. I've push

Re: Cancelled: LilyPond meeting in Waltrop, Germany, 2013-09-20 to 2013-09-24

:( 2013/9/17 David Kastrup : > David Kastrup writes: > >> This is a reminder that next weekend, Sept 20th to 24th, there will be a >> LilyPond developer and user meeting in Waltrop, Germany. > > Ok, the current possible participant list would look like the following: > Jan, Janek, Harm and myself

PATCHES: Countdown for September 21st - 06:00 GMT

Hello, Seems I am back on-line. Thanks for filling in David et al. *Countdown -- September 21st -- 06:00 GMT* * * * * * * * * 3495

Re: Docs: new defaults for rehearsal mark alignment (issue 13300048)

https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely#newcode86 Documentation/changes.tely:86: of the clef and key signature by default. As in previous ver

Re: Measure 'staff-padding' to reference points, as claimed in its docstring (issue 7005056)

https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/tweaks.itely File Documentation/learning/tweaks.itely (right): https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/tweaks.itely#newcode2987 Documentation/learning/tweaks.itely:2987: \override DynamicLin

Re: Docs: new defaults for rehearsal mark alignment (issue 13300048)

Reviewers: J_lowe, thomasmorley651, Mark Polesky, https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely#newcode86 Documentation/changes.tely:86: of the cl

Re: Measure 'staff-padding' to reference points, as claimed in its docstring (issue 7005056)

On 2013/09/18 23:45:37, Mark Polesky wrote: I think we should stop using the `#' for scheme numbers. But when it is time to make that change, we would make the change over all the documentation at once. https://codereview.appspot.com/7005056/ ___

`opus' header field at surprising position

Folks, consider this snippet (image attached): \header { title = "title" opus = "opus" composer = "composer" copyright = "" footer = "" tagline = "" } \markup { top1 } \markup { top2 } \markup { top3 } \score { c''1 } I would expect that `opus' appears ver

Re: `opus' header field at surprising position

2013/9/19 Werner LEMBERG : > I would expect that `opus' appears vertically before `top1'. > > Is this a bug? Otherwise, I suggest to change the code so that the > header block really stays together. I suppose that this is a consequence of having _two_ header blocks - one for \book and one for \sc