Han-Wen Nienhuys <hanw...@gmail.com> writes: > On Sun, May 10, 2020 at 11:37 AM David Kastrup <d...@gnu.org> wrote: >> >> Han-Wen Nienhuys <hanw...@gmail.com> writes: >> >> > Sorry. I'm fine with the migration going through today. >> > >> > We'll all be confused for a few days, but given that gitlab is more >> > standard infrastructure than what we have, I think we'll figure it >> > out. >> > >> > I suggest: >> > >> > * removing write access to issue tracker from me, so patch upload >> > fails appropriately >> > * stopping the job that mirrors staging => master (I think it runs >> > automatically?) >> >> Semiautomatically these days. Why would that task need stopping? It >> would just need to get run with the Gitlab repository instead, or am I >> misunderstanding anything here? > > I think it would be good if nobody commits to either GL or savannah > during the migration, to not muddle the waters. Afterwards, it can > work off GL.
commit d99780e93bfeafbcafce1c2653eac8e294057e84 (origin/staging) Author: Han-Wen Nienhuys <han...@lilypond.org> Date: Sat May 9 11:49:03 2020 +0200 output-distance: set device properties in batch driver file This fixes the output quality of the regtest results. Previously, the code sets a device by doing (png16m) finddevice this put a default device on the stack, ignoring the command-line arguments. To fix this, specify these settings (HWResolution, TextAlphaBits, GraphicsAlphaBits) as arguments to the putdeviceprops call. https://codereview.appspot.com/560020043/ https://sourceforge.net/p/testlilyissues/issues/5967/ How do you expect that commit you just now pushed to proceed if not via Patchy? -- David Kastrup