PATCHES - Countdown for May 21st

2020-05-21 Thread James
Hello, Here is the current patch countdown list. The next countdown will be on May 23rd A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !58 Doc typos: remove double backslash in `@code{}` - Valentin

Re: Markup vertical alignment

2020-05-21 Thread Valentin Villenave
On 5/21/20, James wrote: > A bit like this (still open) issue? > https://sourceforge.net/p/testlilyissues/issues/1322/ > ;) Uh, that’s precisely one I’m trying to close… :-) https://gitlab.com/lilypond/lilypond/-/merge_requests/59 > Mind you I was sure there was some discussion in dev-lilypond

Re: Markup vertical alignment

2020-05-21 Thread James
Hello, On 20/05/2020 19:36, Valentin Villenave wrote: By the way, isn’t it time to retire \null? Or at least change its oh-so-deceptive name. (\point might be confusing in another way, though; I’m open to suggestions.) Cheers, -- V. A bit like this (still open) issue?

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread Han-Wen Nienhuys
On Thu, May 21, 2020 at 12:34 PM Jonas Hahnfeld wrote: > > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: > > > before merging. As we only allow fast-forward merges, this means each > > > MR has received testing in the form it hits

Re: mirror GitLab -> Savannah

2020-05-21 Thread Jonas Hahnfeld
Am Samstag, den 16.05.2020, 11:49 +0200 schrieb Jonas Hahnfeld: > Am Donnerstag, den 14.05.2020, 20:31 +0200 schrieb Jonas Hahnfeld: > > To keep this short: I'd like to enable push mirroring from GitLab to > > Savannah for the following branches [1]: > > - master > > - release/unstable > > -

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread James
On 21/05/2020 12:02, Han-Wen Nienhuys wrote: so a next step might be making the countdown process more continuous. What does that mean - even conceptually? The countdown is specifically to allow everyone some time to breathe and digest patches submitted without the fear of having to be

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread Jonas Hahnfeld
Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: > > before merging. As we only allow fast-forward merges, this means each > > MR has received testing in the form it hits master. This would > > effectively replace the current setup of

scorio contact?

2020-05-21 Thread Han-Wen Nienhuys
Are the scorio folks on this list? Is scorio still being worked on? Does anyone know how it makes stencils appear on their web interface? I am looking into cleaning up how we generate PS and SVG files, and I don't want to make their lives harder than necessary. -- Han-Wen Nienhuys -

Re: scorio contact?

2020-05-21 Thread Jürgen Reuter
At least, two of the (former?) scorio people (Johannes Feulner and Dominik Hörnel) were attending in Salzburg, if that helps to get in contact with them, and Johannes is in the list of my FB friends IIRC. On Thu, May 21, 2020 at 10:42 PM Han-Wen Nienhuys wrote: Are the

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread Jonas Hahnfeld
Am Donnerstag, den 21.05.2020, 18:25 +0200 schrieb David Kastrup: > > If we think contention will be a problem, we cannot do the proposal. > > There's no sane "mixed bag": As outlined initially, we would 1) > > require CI for merge requests, and 2) disable direct pushes to > > master. This

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread David Kastrup
Jonas Hahnfeld writes: > Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup: >> > > Jonas Hahnfeld writes: >> > > > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:

Re: LilyPond GSoC logistics

2020-05-21 Thread Urs Liska
Am 21. Mai 2020 19:21:27 MESZ schrieb Owen Lamb : >> >> To preserve your code within LilyPond it probably makes sense if you >put >> your code into a private (but public) branch of the upstream lilypond >> repository (i.e., not a gitlab clone of it), for example >> 'dev/lamb/GSoC-2020'. >> >

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread Jonas Hahnfeld
Am Donnerstag, den 21.05.2020, 17:21 +0200 schrieb Han-Wen Nienhuys: > On Thu, May 21, 2020 at 1:17 PM James wrote: > > On 21/05/2020 12:02, Han-Wen Nienhuys wrote: > > > so a next step might be making the countdown process more > > > continuous. > > > > What does that mean - even conceptually?

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread Jonas Hahnfeld
Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup: > > > Jonas Hahnfeld writes: > > > > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: > > > > > The "traffic jam"

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread David Kastrup
Jonas Hahnfeld writes: > Am Donnerstag, den 21.05.2020, 17:21 +0200 schrieb Han-Wen Nienhuys: >> On Thu, May 21, 2020 at 1:17 PM James wrote: >> > On 21/05/2020 12:02, Han-Wen Nienhuys wrote: >> > > so a next step might be making the countdown process more >> > > continuous. >> > >> > What

Re: LilyPond GSoC logistics

2020-05-21 Thread Owen Lamb
> > To preserve your code within LilyPond it probably makes sense if you put > your code into a private (but public) branch of the upstream lilypond > repository (i.e., not a gitlab clone of it), for example > 'dev/lamb/GSoC-2020'. > I'm a bit confused here, so let me just make sure I understand

convert-ly doesn't find lilylib

2020-05-21 Thread Jean-Charles Malahieude
Hi, with master as of 15de2c8874262c2c0a9f2cc3beee5070c766dde4 $ cat buggy.ly \version "2.18.2" c1 $ ~/GIT/Mentor/out/bin/convert-ly -e TEST.ly Traceback (most recent call last): File "/home/jcharles/GIT/Mentor/out/bin/convert-ly", line 65, in import lilylib as ly ModuleNotFoundError:

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread David Kastrup
Jonas Hahnfeld writes: > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: >> On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: >> > before merging. As we only allow fast-forward merges, this means each >> > MR has received testing in the form it hits master. This would >> > effectively

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread Jonas Hahnfeld
Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: > > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: > > > > before merging. As we only allow fast-forward merges, this means each > > > >

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread David Kastrup
Jonas Hahnfeld writes: > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: >> > > On May 17, 2020, at 15:27, Jonas Hahnfeld wrote: >> > > > before merging. As we only allow fast-forward

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread David Kastrup
Jonas Hahnfeld writes: > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: >> > > The "traffic jam" problem could be avoided by retaining the option of >> > > pushing to staging.

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread Han-Wen Nienhuys
On Thu, May 21, 2020 at 1:17 PM James wrote: > > > On 21/05/2020 12:02, Han-Wen Nienhuys wrote: > > so a next step might be making the countdown process more > > continuous. > > What does that mean - even conceptually? My idea is that patches could enter 'countdown' stage throughout the day, and

Re: [RFC] Enabling GitLab CI

2020-05-21 Thread Jonas Hahnfeld
Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: > > > The "traffic jam" problem could be avoided by retaining the option of > > > pushing to staging. That would occur without CI, but