Re: migrating to GitLab

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sun, May 10, 2020 at 11:37 AM David Kastrup <address@hidden> wrote:
>>
>> Han-Wen Nienhuys <address@hidden> 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 <address@hidden>
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