Re: Issue 3128: add Haydn-style turns to Feta (issue 340660043 by lilyp...@maltemeyn.de)

On 2018/04/08 18:05:49, Dan Eble wrote: Having two symbols available does not necessarily require having unique commands for them. For example, LilyPond supports different styles of multi-measure rests, but they're all represented with R. I'm trying to understand whether these scripts are

PATCHES - Countdown for April 9th

Hello, Here is the current patch countdown list. The next countdown will be on April 12th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5300 makelsr.py: don't delete the output directory - Dan Eble https:/

Allura/SourceForge to Gitlab migration

Hi I don't want to revamp this old discussion: http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00095.html http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00140.html This is just a call for all contributors who are not quite satisfied with current setup and think that mov

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 11:06 AM, Federico Bruni wrote: This is just a call for all contributors who are not quite satisfied with current setup and think that moving to Gitlab "one day™" might be an improvement. Do you want the discussion limited to just the Gitlab proposal, or expanded to the larger wor

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 11:06 AM, Federico Bruni wrote: I don't want to revamp this old discussion: http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00095.html http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00140.html I should have read those BEFORE making my other post. Current o

Re: Allura/SourceForge to Gitlab migration

Hello, On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High wrote: > On 4/9/2018 11:06 AM, Federico Bruni wrote: > > > > I don't want to revamp this old discussion: > > http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00095.html > > http://lists.gnu.org/archive/html/lilypond-devel/2013-10/

Re: Allura/SourceForge to Gitlab migration

On 4/9/18, 12:06 PM, "lilypond-devel on behalf of James Lowe" wrote: Hello, Does Gitlab really only just have 2 status for an 'issue' (Open and Closed) or can this be refined/configured so I (as Patch Meister) can keep track of what is 'making its way through' the patch co

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 1:13 PM, Carl Sorensen wrote: In my GitLab usage we use tags. This feature, perhaps? -- Karlin High Missouri, USA ___ lilypond-devel mailing list lilyp

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 11:06 AM, Federico Bruni wrote: This is just a call for all contributors who are not quite satisfied with current setup and think that moving to Gitlab "one day™" might be an improvement. Which edition of Gitlab should we be looking at for this discussion? Or are the feature differe

Re: Allura/SourceForge to Gitlab migration

On 4/9/18, 12:14 PM, "Karlin High" wrote: On 4/9/2018 1:13 PM, Carl Sorensen wrote: > In my GitLab usage we use tags. This feature, perhaps? Yes, we attach labels to issues. And th

Re: Allura/SourceForge to Gitlab migration

Am 9. April 2018 20:06:20 MESZ schrieb James Lowe : >Hello, > >On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High >wrote: > >> On 4/9/2018 11:06 AM, Federico Bruni wrote: >> > >> > I don't want to revamp this old discussion: >> > >http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00095.ht

Re: Allura/SourceForge to Gitlab migration

On 4/9/18, 1:04 PM, "lilypond-devel on behalf of Urs Liska" wrote: Am 9. April 2018 20:06:20 MESZ schrieb James Lowe : >Hello, > >On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High >wrote: > >> On 4/9/2018 11:06 AM, Federico Bruni wrote: >> > >> > I do

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 2:15 PM, Carl Sorensen wrote: If we use merges instead of single commits, we know that the final result (the merge commit) is OK, but we don't know anything about the underlying commits in the branch being merged. Some of those commits may not build properly. I guess those commit

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 3:05 PM, Karlin High wrote: Whether terms of service and such are aligned with GNU standards is something I haven't checked. ...But if projects like Debian and GNOME are using GitLab, as Federico Bruni pointed out, the chances of a terms-of-service conflict with GNU and FSF seem r

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 3:23 PM, Karlin High wrote: Whether terms of service and such are aligned with GNU standards is something I haven't checked. ...But if projects like Debian and GNOME are using GitLab, as Federico Bruni pointed out, the chances of a terms-of-service conflict with GNU and FSF seem r

Re: Allura/SourceForge to Gitlab migration

Il giorno lun 9 apr 2018 alle 22:23, Karlin High ha scritto: On 4/9/2018 3:05 PM, Karlin High wrote: Whether terms of service and such are aligned with GNU standards is something I haven't checked. ...But if projects like Debian and GNOME are using GitLab, as Federico Bruni pointed out,

Re: Allura/SourceForge to Gitlab migration

Am 09.04.2018 um 22:57 schrieb Federico Bruni: Il giorno lun 9 apr 2018 alle 22:23, Karlin High ha scritto: On 4/9/2018 3:05 PM, Karlin High wrote: Whether terms of service and such are aligned with GNU standards is something I haven't checked. ...But if projects like Debian and GNOME

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 3:57 PM, Federico Bruni wrote: Well, of course they use the open source version, the community edition (gitlab-ce). See for example: http://metadata.ftp-master.debian.org/changelogs/contrib/g/gitlab/gitlab_10.6.3+dfsg-1_copyright "Debian is runni

Re: Allura/SourceForge to Gitlab migration

On 4/9/18, 3:43 PM, "Karlin High" wrote: I wasn't clear on whether the free-Gold-tier-for-open-source was automatic for any public repository, or if it needed GitLab approval. So I tried it out, and the paid-version "squash and merge" feature IS available in public repos

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 4:51 PM, Carl Sorensen wrote: The problem with this workflow is that the merger is the person who needs to do the squash-and-merge. That's extra work for the merger. I'd prefer to keep the work on the patch creator. GitLab actually gave me the "squash" option at both points, req

Re: Allura/SourceForge to Gitlab migration

Am 09.04.2018 um 21:15 schrieb Carl Sorensen: On 4/9/18, 1:04 PM, "lilypond-devel on behalf of Urs Liska" wrote: Am 9. April 2018 20:06:20 MESZ schrieb James Lowe : >Hello, > >On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High >wrote: > >> On 4/9

Re: Issue 5301: Refactor mark events ... (issue 340650043 by nine.fierce.ball...@gmail.com)

https://codereview.appspot.com/340650043/diff/1/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/340650043/diff/1/ly/music-functions-init.ly#newcode833 ly/music-functions-init.ly:833: #(define-music-function (label) ((integer-or-markup?)) Alterna

Re: Allura/SourceForge to Gitlab migration

On 4/9/2018 2:15 PM, Carl Sorensen wrote: Right now, our current process ensures that every commit on master builds properly -- master never gets broken. The only branch that can get broken is staging. Another thing: Repository mirroring