migrating to GitLab

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

David Kastrup
Han-Wen Nienhuys <[hidden email]> writes:

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

Sure.  But as long as nobody pushes to staging, nothing will get to
master anyway.

I just remembered: we should not be mirroring staging since Savannah
will refuse any non-ff push to any branch, and staging will be non-ff
whenever something needs to get backed out of it.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

David Kastrup
In reply to this post by Han-Wen Nienhuys-3
Han-Wen Nienhuys <[hidden email]> writes:

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

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

David Kastrup
David Kastrup <[hidden email]> writes:

> Han-Wen Nienhuys <[hidden email]> writes:
>
>> On Sun, May 10, 2020 at 11:37 AM David Kastrup <[hidden email]> wrote:
>>>
>>> Han-Wen Nienhuys <[hidden email]> 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 <[hidden email]>
> 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?

I am running Patchy right now (it's not just this commit but also a few
by Jonas) but it would make sense if nobody pushed anything afterwards.

My Patchy runs take about 40 minutes I think.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Han-Wen Nienhuys-3
In reply to this post by David Kastrup
On Sun, May 10, 2020 at 11:57 AM David Kastrup <[hidden email]> wrote:

>     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?

I'd push it again, I guess? IIRC I pushed this before reading Jonas
request for comments.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

David Kastrup
Han-Wen Nienhuys <[hidden email]> writes:

> On Sun, May 10, 2020 at 11:57 AM David Kastrup <[hidden email]> wrote:
>
>>     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?
>
> I'd push it again, I guess? IIRC I pushed this before reading Jonas
> request for comments.

Yes, I misread the date.  The commit _time_ looked like it was just now,
but the date (of the rebase most likely) yesterday.

Sorry for that mistake.  I still think it makes sense to let the Patchy
run complete in order to leave a reasonably clean slate on Savannah.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Jonas Hahnfeld
In reply to this post by David Kastrup
Am Sonntag, den 10.05.2020, 11:59 +0200 schrieb David Kastrup:
> I am running Patchy right now (it's not just this commit but also a few
> by Jonas) but it would make sense if nobody pushed anything afterwards.

Famous last words. In any case, if something gets to the wrong repo or
branch, it's rather easy to correct with git. At least much easier than
comments to issues or new issues on SF. But that isn't of relevance
either until I disable write access (planning ~21:00 CEST, 19:00 UTC).

(Currently gitlab.com is performing database maintenance and Savannah
had some hiccups as well; I'm taking this as a sign that it can only
get better today...)

> My Patchy runs take about 40 minutes I think.

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Werner LEMBERG
In reply to this post by Jonas Hahnfeld

> In any case it's not clear to me whether I should prepare for the
> migration today or not. This would be less frustrating if other
> high- volume developers (including but not limited to David,
> Han-Wen, Werner) commented on the plan...

I like it, so please proceed!  And thanks for working against the
phlegm of all of us.


    Werner

Reply | Threaded
Open this post in threaded view
|

README.md (was: migrating to GitLab)

Urs Liska-3
In reply to this post by Jonas Hahnfeld
Hello all,

although I have admittedly been pretty much silent about all this I
would like to ask about getting access to the LilyPond repository in
the new place as well. My user name there is urs.liska.

One thing I noted while setting up my account is that we don't have a
README.md in the root directory. Is this by any conscious decision or
simply because nobody has done it or started a discussion yet?

I think having such a file as a first - auto-formatted - introduction
on a repository's entry page is a common expectation for any visitor of
this kind of platform. Not finding general information on the front
page would be irritating for most visitors (and potential
contributors).

This is to start a discussion of what should be on that page before
writing one and starting a Merge Request.

I think a README.md should include:

 * A general description of what LilyPond is, with a reference to the
   website and a direct link to the manuals
 * An initial overview of how to become a contributor with
    * a description of the used programming languages
    * a list of included support tools with their programming languages
      (e.g. musicxml2ly)
    * a link to the CG
    * maybe a quick reference about what we expect Merge Requests to
      look like

Best
Urs

Am Freitag, den 08.05.2020, 08:57 +0200 schrieb Jonas Hahnfeld:

> I haven't heard further objections which, for me, means we are going
> with GitLab. If you don't agree, now's your final time to speak up.
> Otherwise I would like to tackle the migration rather soon to take
> advantage of the new opportunities :-)
>
> This leads me to some final considerations:
> 1) I'm going to disable write access to SourceForge when starting the
> migration. Otherwise the two copies will diverge over time, leading
> to
> confusion for everyone. As all old issues are retained, including
> their
> ticket numbers, this shouldn't be a problem: We can just continue
> working on them and preferably close the issues over time ;-)
>
> 2) I'm not attempting to migrate outstanding patches from Rietveld.
> As
> we'll most probably have some during the switch, they need to be
> resubmitted. This shouldn't be a major deal as everybody should be
> working with branches already. Right?
>
> 3) The idea is to have the "main" repository at GitLab, next to the
> issues and merge requests. This leads to the question what to do with
> Savannah because git is distributed anyway. I first thought about
> only
> pushing "important" branches and tags to GitLab (master, stable/*,
> release/*). Switching platforms would actually be one of the few
> opportunities to do so - in particular tags are hard to get rid of.
> However most of us are probably going to reuse their local
> repository,
> just updating the URL. While GitLab has options to prevent pushing
> certain refs, that's probably not a great idea. So I guess I'll just
> push an identical copy to GitLab unless somebody has a better
> proposal.
>
> Ultimately we can talk about cleaning up the Savannah repo and only
> keeping the "important" branches there. This could for example be
> coupled with automated mirroring, which GitLab supports out-of-the-
> box.
> I won't look into this for the initial switch though, so just make
> sure
> you're not pushing conflicting commits there...
>
> 4) I expect the script to take 9-10 hours for the issue migration
> which
> I plan to run over night (European time). This is primarily for post-
> processing tasks at the end which are better done when fully awake.
> So
> no issue tracker during this time, but that's probably justifiable.
>
> ---
>
> And now to the most important task: picking a date when I'm
> available.
> I could do: Sunday evening & Monday; Tuesday & Wednesday; or
> Wednesday
> & Thursday.
>
> Cheers
> Jonas


Reply | Threaded
Open this post in threaded view
|

Re: README.md

James Lowe-9
On 17/05/2020 08:54, Urs Liska wrote:
> One thing I noted while setting up my account is that we don't have a
> README.md in the root directory. Is this by any conscious decision or
> simply because nobody has done it or started a discussion yet?

No discussion.

We're still in a transition stage though Urs - sorting out Gitlab labels
and the workflow etc. So there will be a few things like this that
haven't been decided on yet.

If you want to get something started it may be better done in an 'issue'
that can be discussed rather than just by email (once you get yourself
sorted and familiar with gitlab).

Regards

James


Reply | Threaded
Open this post in threaded view
|

Re: README.md (was: migrating to GitLab)

Han-Wen Nienhuys-3
In reply to this post by Urs Liska-3
On Sun, May 17, 2020 at 9:55 AM Urs Liska <[hidden email]> wrote:

>
> Hello all,
>
> although I have admittedly been pretty much silent about all this I
> would like to ask about getting access to the LilyPond repository in
> the new place as well. My user name there is urs.liska.
>
> One thing I noted while setting up my account is that we don't have a
> README.md in the root directory. Is this by any conscious decision or
> simply because nobody has done it or started a discussion yet?

We have README.txt (generated from a .texi in Documentation/topdocs),
and ROADMAP. I think it would be a great idea if someone would
reformat the contents into a README.md file in the root of the tree.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen

Reply | Threaded
Open this post in threaded view
|

Re: README.md (was: migrating to GitLab)

Urs Liska-3
Am Sonntag, den 17.05.2020, 10:01 +0200 schrieb Han-Wen Nienhuys:

> On Sun, May 17, 2020 at 9:55 AM Urs Liska <[hidden email]>
> wrote:
> > Hello all,
> >
> > although I have admittedly been pretty much silent about all this I
> > would like to ask about getting access to the LilyPond repository
> > in
> > the new place as well. My user name there is urs.liska.
> >
> > One thing I noted while setting up my account is that we don't have
> > a
> > README.md in the root directory. Is this by any conscious decision
> > or
> > simply because nobody has done it or started a discussion yet?
>
> We have README.txt (generated from a .texi in Documentation/topdocs),
> and ROADMAP. I think it would be a great idea if someone would
> reformat the contents into a README.md file in the root of the tree.

My offer was to write a README.md after some discussions, but of course
reworking an existing resource is an even better approach.

Do I understand you correctly that README.txt is generated upon
compiling LilyPond? So where does it end up, I couldn't find a
README.txt neither in the source repository nor in the installation
directory. Does it only end up in the documentation (which I haven't
built locally)?

Urs

>


Reply | Threaded
Open this post in threaded view
|

Re: README.md (was: migrating to GitLab)

Kevin Barry
On Sun, May 17, 2020 at 10:08:12AM +0200, Urs Liska wrote:
> Do I understand you correctly that README.txt is generated upon
> compiling LilyPond? So where does it end up, I couldn't find a
> README.txt neither in the source repository nor in the installation
> directory. Does it only end up in the documentation (which I haven't
> built locally)?

It gets built during a normal make all build. The source seems to be
Documentation/topdocs/README.texi. The built version seems to appear in
Documentation/topdocs/out.

Reply | Threaded
Open this post in threaded view
|

Re: README.md (was: migrating to GitLab)

Han-Wen Nienhuys-3
In reply to this post by Urs Liska-3
On Sun, May 17, 2020 at 10:08 AM Urs Liska <[hidden email]> wrote:

>
> Am Sonntag, den 17.05.2020, 10:01 +0200 schrieb Han-Wen Nienhuys:
> > On Sun, May 17, 2020 at 9:55 AM Urs Liska <[hidden email]>
> > wrote:
> > > Hello all,
> > >
> > > although I have admittedly been pretty much silent about all this I
> > > would like to ask about getting access to the LilyPond repository
> > > in
> > > the new place as well. My user name there is urs.liska.
> > >
> > > One thing I noted while setting up my account is that we don't have
> > > a
> > > README.md in the root directory. Is this by any conscious decision
> > > or
> > > simply because nobody has done it or started a discussion yet?
> >
> > We have README.txt (generated from a .texi in Documentation/topdocs),
> > and ROADMAP. I think it would be a great idea if someone would
> > reformat the contents into a README.md file in the root of the tree.
>
> My offer was to write a README.md after some discussions, but of course
> reworking an existing resource is an even better approach.
>
> Do I understand you correctly that README.txt is generated upon
> compiling LilyPond? So where does it end up, I couldn't find a
> README.txt neither in the source repository nor in the installation
> directory. Does it only end up in the documentation (which I haven't
> built locally)?

Documentation/topdocs/README.texi

it's shipped in the root directory of our source tarballs.


--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen

Reply | Threaded
Open this post in threaded view
|

Re: README.md

David Kastrup
In reply to this post by Han-Wen Nienhuys-3
Han-Wen Nienhuys <[hidden email]> writes:

> On Sun, May 17, 2020 at 9:55 AM Urs Liska <[hidden email]> wrote:
>>
>> Hello all,
>>
>> although I have admittedly been pretty much silent about all this I
>> would like to ask about getting access to the LilyPond repository in
>> the new place as well. My user name there is urs.liska.
>>
>> One thing I noted while setting up my account is that we don't have a
>> README.md in the root directory. Is this by any conscious decision or
>> simply because nobody has done it or started a discussion yet?
>
> We have README.txt (generated from a .texi in Documentation/topdocs),
> and ROADMAP. I think it would be a great idea if someone would
> reformat the contents into a README.md file in the root of the tree.

If the source is .texi, there should be automated tool chains available
(possibly via Docbook?) for creating md.  While that may sound like
overkill just for the README, the tools would also permit washing things
like the Changes document into the Wiki(?).

--
David Kastrup

12