migrating to GitLab

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

migrating to GitLab

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

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

Re: migrating to GitLab

Jean-Charles Malahieude-2
Le 08/05/2020 à 08:57, Jonas Hahnfeld a écrit :

> 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:
> [...]
>
> 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.
>

Please don't forget the translation branch. BTW, will the merry-go-round
(master->translation->staging) have to be played the same way?

Cheers,
--
Jean-Charles

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Jonas Hahnfeld
Am Freitag, den 08.05.2020, 10:17 +0200 schrieb Jean-Charles
Malahieude:

> Le 08/05/2020 à 08:57, Jonas Hahnfeld a écrit :
> > 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:
> > [...]
> >
> > 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.
> >
>
> Please don't forget the translation branch.
See, another reason to go with all branches because it's easy to miss
one. Not that it would be hard to just push it afterwards, but taking
all eliminates any possible loss.

> BTW, will the merry-go-round (master->translation->staging) have to be played the same way?

For now yes: The process stays the same, including all branches. But
there are certainly possibilities for improvement 😉 I'm alread
y thinking about some, I'll start proper discussions once ready...

Jonas

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

Re: migrating to GitLab

Valentin Villenave-3
In reply to this post by Jonas Hahnfeld
On 5/8/20, Jonas Hahnfeld <[hidden email]> wrote:
> 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.

Thanks for tackling this!

> 3) The idea is to have the "main" repository at GitLab, next to the
> issues and merge requests.

If the two are kept in sync (if and when you enable mirroring), does
that mean some of us can keep pushing onto Savannah without any
difference whatsoever? (Except perhaps for the few minutes time-lag
it’d take for commits to propagate.)

> Ultimately we can talk about cleaning up the Savannah repo and only
> keeping the "important" branches there.

Counterpoint: unlike GitLab, Savannah 1/ has been around for a long
time and 2/ relies on a non-profit foundation with lots of volunteers
(although its resources are obviously stretched thin). This leads me
to believe (perhaps superstitiously) that Savannah may have a
marginally better chance of staying around for longer than GitLab;
thus removing "historical" branches from Savannah may come to bite us
in the ass in decades to come, in case GitLab goes suddenly bankrupt
or decides to cease Free-Software support or whatever.

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

I once seemed to notice that Mondays are traditionally low-activity.
(But that was another world back then.)

Cheers, and thanks again!
-- V.

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Jonas Hahnfeld
Am Freitag, den 08.05.2020, 11:03 +0200 schrieb Valentin Villenave:
> On 5/8/20, Jonas Hahnfeld <[hidden email]> wrote:
> > 3) The idea is to have the "main" repository at GitLab, next to the
> > issues and merge requests.
>
> If the two are kept in sync (if and when you enable mirroring), does
> that mean some of us can keep pushing onto Savannah without any
> difference whatsoever?

The mirroring is directional, in our case from GitLab to Savannah, so
no real synchronization.

> (Except perhaps for the few minutes time-lag it’d take for commits to propagate.)

This is exactly the problem, for example with conflicting commits in
the two master branches. I don't think we should risk this, the GitLab
documentation explicitly states "Bidirectional mirroring may cause
conflicts".
What we could do is mirror a subset of the dev branches from Savannah
to GitLab. Not sure how this could be used, but this would need a
really compelling reason to warrant the complexity.

> > Ultimately we can talk about cleaning up the Savannah repo and only
> > keeping the "important" branches there.
>
> Counterpoint: unlike GitLab, Savannah 1/ has been around for a long
> time and 2/ relies on a non-profit foundation with lots of volunteers
> (although its resources are obviously stretched thin). This leads me
> to believe (perhaps superstitiously) that Savannah may have a
> marginally better chance of staying around for longer than GitLab;
> thus removing "historical" branches from Savannah may come to bite us
> in the ass in decades to come, in case GitLab goes suddenly bankrupt
> or decides to cease Free-Software support or whatever.
Granted, but how likely is it that a dev branch from 10 years ago will
be of interest in a decade or so?
In any case, we can export the project from gitlab.com to prevent loss
if that is of concern.

Jonas

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

Re: migrating to GitLab

David Kastrup
In reply to this post by Jonas Hahnfeld
Jonas Hahnfeld <[hidden email]> writes:

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

What kind of mirroring options are there?  I think it makes sense for
the non-developer access to keep referring/pointing to Savannah since I
consider it a resource with more long-term dependable availability.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Jonas Hahnfeld
Am Freitag, den 08.05.2020, 13:07 +0200 schrieb David Kastrup:

> Jonas Hahnfeld <[hidden email]> writes:
>
> > 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...
>
> What kind of mirroring options are there?
Here's the documentation:
https://gitlab.com/help/user/project/repository/repository_mirroring.md

> I think it makes sense for
> the non-developer access to keep referring/pointing to Savannah since I
> consider it a resource with more long-term dependable availability.

That is exactly the motivation. Syncing master (and a few others) from
GitLab to Savannah should satisfy this need.

Jonas

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

Re: migrating to GitLab

James Lowe-9
On 08/05/2020 12:21, Jonas Hahnfeld wrote:

> Am Freitag, den 08.05.2020, 13:07 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <[hidden email]> writes:
>>
>>> 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...
>> What kind of mirroring options are there?
> Here's the documentation:
> https://gitlab.com/help/user/project/repository/repository_mirroring.md
>
>> I think it makes sense for
>> the non-developer access to keep referring/pointing to Savannah since I
>> consider it a resource with more long-term dependable availability.
> That is exactly the motivation. Syncing master (and a few others) from
> GitLab to Savannah should satisfy this need.
>
> Jonas

As a courtesy many moons ago, I started to cut/paste the commit hash and
message/title in the issues so that the squad that verified the fixes
could quickly find them.

I still do that, is it useful?

I am assuming that the commit hashes will be mirrored as well or,
assuming this convention of cutting pasting the commit into the issue is
still useful when on gitlab.

James


Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Jonas Hahnfeld
Am Freitag, den 08.05.2020, 19:10 +0100 schrieb James Lowe:

> On 08/05/2020 12:21, Jonas Hahnfeld wrote:
> > Am Freitag, den 08.05.2020, 13:07 +0200 schrieb David Kastrup:
> > > Jonas Hahnfeld <[hidden email]> writes:
> > >
> > > > 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...
> > >
> > > What kind of mirroring options are there?
> >
> > Here's the documentation:
> > https://gitlab.com/help/user/project/repository/repository_mirroring.md
> >
> >
> > > I think it makes sense for
> > > the non-developer access to keep referring/pointing to Savannah since I
> > > consider it a resource with more long-term dependable availability.
> >
> > That is exactly the motivation. Syncing master (and a few others) from
> > GitLab to Savannah should satisfy this need.
> >
> > Jonas
>
> As a courtesy many moons ago, I started to cut/paste the commit hash and
> message/title in the issues so that the squad that verified the fixes
> could quickly find them.
After the migration, we can put "Closes #1234" in the commit message
and GitLab will close the related issue once the commit hits master.

> I still do that, is it useful?

still useful for issues closed on SourceForge

> I am assuming that the commit hashes will be mirrored as well or,
> assuming this convention of cutting pasting the commit into the issue is
> still useful when on gitlab.

Yes, the git repo will stay the same, only hosted somewhere else for
development.

So what's the feeling about the migration? go / no-go for tomorrow?

Jonas

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

Re: migrating to GitLab

Carl Sorensen-3
On 5/9/20, 12:13 PM, "lilypond-devel on behalf of Jonas Hahnfeld" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> wrote:

<snip>
So what's the feeling about the migration? go / no-go for tomorrow?

->CS  Do we have a revision to the CG to go with the migration?  I haven't seen any red flags that cause me to oppose the migration.  I love the idea of going from 3 platforms (Savannah, SourceForge, Rietveld) to one (GitLab).  But I'm a little conflicted, as I prefer the code review experience on Rietveld.

->CS  At any rate, I think that we should have appropriate CG instructions at the time we make the switch.  They don't have to be perfect (the CG has a much lower editing bar than the NR), but they need to be in place, IMO.

Thanks,

Carl


Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

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

> On 5/9/20, 12:13 PM, "lilypond-devel on behalf of Jonas Hahnfeld"
> <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of
> [hidden email]> wrote:
>
> <snip>
> So what's the feeling about the migration? go / no-go for tomorrow?
>
> ->CS Do we have a revision to the CG to go with the migration?  I
> haven't seen any red flags that cause me to oppose the migration.  I
> love the idea of going from 3 platforms (Savannah, SourceForge,
> Rietveld) to one (GitLab).  But I'm a little conflicted, as I prefer
> the code review experience on Rietveld.

I think we'll all need some time to seriously adapt.  Our current setup
is only working semiautomatically and a lot of pieces are filled in
manually by James.  The Gitlab setup will be a lot more standardised and
thus should be easier to work out of the box, but we certainly would
want to keep some pieces of our workflow and of those who actually make
it work, while preferably getting to work with more standardised scripts
hopefully mostly managed by other people.

I would say it makes most sense to stash most feelings of conflict for a
month or two, then revisit them and see how they have developed.

> ->CS At any rate, I think that we should have appropriate CG
> instructions at the time we make the switch.  They don't have to be
> perfect (the CG has a much lower editing bar than the NR), but they
> need to be in place, IMO.

It's sort of a hen and egg problem: if we want to have all that before,
it increases the workload for those preparing the migration and they
have to guess.

I totally agree that the CG should reflect the new workflows.  But at
the time we do the switch, those new workflows are still in flux.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Dan Eble
On May 9, 2020, at 15:13, David Kastrup <[hidden email]> wrote:

> Carl Sorensen <[hidden email]> writes:
>
>> ->CS At any rate, I think that we should have appropriate CG
>> instructions at the time we make the switch.  They don't have to be
>> perfect (the CG has a much lower editing bar than the NR), but they
>> need to be in place, IMO.
>
> It's sort of a hen and egg problem: if we want to have all that before,
> it increases the workload for those preparing the migration and they
> have to guess.
>
> I totally agree that the CG should reflect the new workflows.  But at
> the time we do the switch, those new workflows are still in flux.

I understand Carl's perspective, but I'm on the side of jumping in.  I don't expect that we'll be inundated with newbie contributors between now and the time we figure out what to put in the CG.

Maybe we could put in a minimal note referring to the project on GitLab and explaining that a more thorough CG revision is pending.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Jonas Hahnfeld
In reply to this post by David Kastrup
Am Samstag, den 09.05.2020, 21:13 +0200 schrieb David Kastrup:

> Carl Sorensen <[hidden email]> writes:
> > On 5/9/20, 12:13 PM, "lilypond-devel on behalf of Jonas Hahnfeld"
> > <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of
> > [hidden email]> wrote:
> >
> > <snip>
> > So what's the feeling about the migration? go / no-go for tomorrow?
> >
> > ->CS Do we have a revision to the CG to go with the migration?  I
> > haven't seen any red flags that cause me to oppose the migration.  I
> > love the idea of going from 3 platforms (Savannah, SourceForge,
> > Rietveld) to one (GitLab).  But I'm a little conflicted, as I prefer
> > the code review experience on Rietveld.
>
> I think we'll all need some time to seriously adapt.  Our current setup
> is only working semiautomatically and a lot of pieces are filled in
> manually by James.  The Gitlab setup will be a lot more standardised and
> thus should be easier to work out of the box, but we certainly would
> want to keep some pieces of our workflow and of those who actually make
> it work, while preferably getting to work with more standardised scripts
> hopefully mostly managed by other people.
>
> I would say it makes most sense to stash most feelings of conflict for a
> month or two, then revisit them and see how they have developed.
>
> > ->CS At any rate, I think that we should have appropriate CG
> > instructions at the time we make the switch.  They don't have to be
> > perfect (the CG has a much lower editing bar than the NR), but they
> > need to be in place, IMO.
>
> It's sort of a hen and egg problem: if we want to have all that before,
> it increases the workload for those preparing the migration and they
> have to guess.
>
> I totally agree that the CG should reflect the new workflows.  But at
> the time we do the switch, those new workflows are still in flux.
To add to this: It's my understanding that the uploaded documentation
is built only for releases. So we should strive to update at least the
links in time for 2.21.2 / defer the release until then. But even if I
had the changes ready for the CG (which I have not yet, mostly for the
reasons outlined by David above), it could at most hit master which
people can only build after they found the sources.

That said, I plan to prepare a patch updating the public web page, in
particular the link to issue. This is likely the most important place
for users. Developers should be subscribed to lilypond-devel (or look
at the archives) and the recent message volume makes it fairly obvious
that the tooling is currently in a transition period.

Jonas

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

Re: migrating to GitLab

Jonas Hahnfeld
In reply to this post by Dan Eble
Am Samstag, den 09.05.2020, 16:11 -0400 schrieb Dan Eble:

> On May 9, 2020, at 15:13, David Kastrup <[hidden email]> wrote:
> > Carl Sorensen <[hidden email]> writes:
> > > ->CS At any rate, I think that we should have appropriate CG
> > > instructions at the time we make the switch.  They don't have to be
> > > perfect (the CG has a much lower editing bar than the NR), but they
> > > need to be in place, IMO.
> >
> > It's sort of a hen and egg problem: if we want to have all that before,
> > it increases the workload for those preparing the migration and they
> > have to guess.
> >
> > I totally agree that the CG should reflect the new workflows.  But at
> > the time we do the switch, those new workflows are still in flux.
>
> I understand Carl's perspective, but I'm on the side of jumping in.  I don't expect that we'll be inundated with newbie contributors between now and the time we figure out what to put in the CG.
>
> Maybe we could put in a minimal note referring to the project on GitLab and explaining that a more thorough CG revision is pending.
Sure, I can prepare such update. But as written roughly the same time
yesterday, we need to release 2.21.2 in order for that to be uploaded.

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

Jonas

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

Re: migrating to GitLab

Han-Wen Nienhuys-3
On Sun, May 10, 2020 at 10:51 AM Jonas Hahnfeld <[hidden email]> wrote:

>
> Am Samstag, den 09.05.2020, 16:11 -0400 schrieb Dan Eble:
> > On May 9, 2020, at 15:13, David Kastrup <[hidden email]> wrote:
> > > Carl Sorensen <[hidden email]> writes:
> > > > ->CS At any rate, I think that we should have appropriate CG
> > > > instructions at the time we make the switch.  They don't have to be
> > > > perfect (the CG has a much lower editing bar than the NR), but they
> > > > need to be in place, IMO.
> > >
> > > It's sort of a hen and egg problem: if we want to have all that before,
> > > it increases the workload for those preparing the migration and they
> > > have to guess.
> > >
> > > I totally agree that the CG should reflect the new workflows.  But at
> > > the time we do the switch, those new workflows are still in flux.
> >
> > I understand Carl's perspective, but I'm on the side of jumping in.  I don't expect that we'll be inundated with newbie contributors between now and the time we figure out what to put in the CG.
> >
> > Maybe we could put in a minimal note referring to the project on GitLab and explaining that a more thorough CG revision is pending.
>
> Sure, I can prepare such update. But as written roughly the same time
> yesterday, we need to release 2.21.2 in order for that to be uploaded.
>
> 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...

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

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

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

David Kastrup
In reply to this post by Jonas Hahnfeld
Jonas Hahnfeld <[hidden email]> writes:

> Am Samstag, den 09.05.2020, 16:11 -0400 schrieb Dan Eble:
>> On May 9, 2020, at 15:13, David Kastrup <[hidden email]> wrote:
>> > Carl Sorensen <[hidden email]> writes:
>> > > ->CS At any rate, I think that we should have appropriate CG
>> > > instructions at the time we make the switch.  They don't have to be
>> > > perfect (the CG has a much lower editing bar than the NR), but they
>> > > need to be in place, IMO.
>> >
>> > It's sort of a hen and egg problem: if we want to have all that before,
>> > it increases the workload for those preparing the migration and they
>> > have to guess.
>> >
>> > I totally agree that the CG should reflect the new workflows.  But at
>> > the time we do the switch, those new workflows are still in flux.
>>
>> I understand Carl's perspective, but I'm on the side of jumping in.
>> I don't expect that we'll be inundated with newbie contributors
>> between now and the time we figure out what to put in the CG.
>>
>> Maybe we could put in a minimal note referring to the project on
>> GitLab and explaining that a more thorough CG revision is pending.
>
> Sure, I can prepare such update. But as written roughly the same time
> yesterday, we need to release 2.21.2 in order for that to be uploaded.
>
> 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 am not looking forward to the transition period but I don't see that
we gain anything by postponing.  And I am glad that you are taking the
initiative here.  So my opinion is to get rolling and see where it gets
us.  And while it would be annoying to have to use it, it's not like we
don't have the old setup as fallback.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Jonas Hahnfeld
In reply to this post by Han-Wen Nienhuys-3
Am Sonntag, den 10.05.2020, 11:05 +0200 schrieb Han-Wen Nienhuys:

> On Sun, May 10, 2020 at 10:51 AM Jonas Hahnfeld <[hidden email]> wrote:
> > 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...
>
> 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
Yes, disabling write access for everyone will be the first step of the
migration as outlined in the initial message.

> * stopping the job that mirrors staging => master (I think it runs
> automatically?)

I'll defer this to David and James who are running the patchy instances
AFAIK. Probably updating the URL somewhere? If I read [1] correctly, a
matter of $ git remote set-url origin <...> in $LILYPOND_GIT?

Jonas

1: http://lilypond.org/doc/v2.19/Documentation/contributor/configuring-patchy

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

Re: migrating to GitLab

Jean-Charles Malahieude-2
In reply to this post by Jonas Hahnfeld
Le 10/05/2020 à 10:50, Jonas Hahnfeld a écrit :

> Am Samstag, den 09.05.2020, 16:11 -0400 schrieb Dan Eble:
>> On May 9, 2020, at 15:13, David Kastrup <[hidden email]> wrote:
>>> Carl Sorensen <[hidden email]> writes:
>>>> ->CS At any rate, I think that we should have appropriate CG
>>>> instructions at the time we make the switch.  They don't have to be
>>>> perfect (the CG has a much lower editing bar than the NR), but they
>>>> need to be in place, IMO.
>>>
>>> It's sort of a hen and egg problem: if we want to have all that before,
>>> it increases the workload for those preparing the migration and they
>>> have to guess.
>>>
>>> I totally agree that the CG should reflect the new workflows.  But at
>>> the time we do the switch, those new workflows are still in flux.
>>
>> I understand Carl's perspective, but I'm on the side of jumping in.  I don't expect that we'll be inundated with newbie contributors between now and the time we figure out what to put in the CG.
>>
>> Maybe we could put in a minimal note referring to the project on GitLab and explaining that a more thorough CG revision is pending.
>
> Sure, I can prepare such update. But as written roughly the same time
> yesterday, we need to release 2.21.2 in order for that to be uploaded.
>
> 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...
>

It's fine with me. The only thing I'll have to know is how I should
adapt my ./git/remotes file to ping the right repo

** traduc **
URL: ssh://[hidden email]/srv/git/lilypond.git/
Push: translation:refs/heads/translation
Pull: translation:refs/remotes/origin/translation
** EOF **

and have "$ git pull traduc" work as usual since 2009.

Cheers,
--
Jean-Charles


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:

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

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: migrating to GitLab

Han-Wen Nienhuys-3
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.

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

12