Re: [gpsd-dev] Upcoming migration to GitLab

[Fred Wright]

On Sat, 25 May 2019, Eric S. Raymond wrote:

> Fred Wright <address@hidden>:
> > > git remote add origin address@hidden:gpsd/gpsd.git
> >
> > That's a simplified forkless version, which I don't think should be the
> > recommended approach.
>
> Good point.
>
> > --- Before the Switch ---
> >
> > Step 1:  Update the gitlab/gpsd/gpsd configuration to allow the usual fork
> > and clone operations, while still being read-only (except for mirroring).
> > There's no reason to refuse MRs in this state, with the caveat that they
> > won't be processed until after the switch.
> >
> > Step 2:  Have devs create GitLab forks and set up their local repos with the
> > three-remote setup described above.  Note that, in this setup, "git fetch
> > --all" will fetch new changes regardless of which repo is "primary", and
> > pushes simply need to specify the appropriate remote name.  Devs using "git
> > pull" would need to pay closer attention to the remote configuration, though
> > I don't personally ever use "git pull" at all, since it's safer and more
> > flexible to do the fetch and merge/rebase separately.
> >
> > Step 3:  Propagate the gpsd group memberships from Savannah to GitLab. That
> > may require some manual effort in cases where the userid mapping isn't
> > obvious.  Step 2 implies that GitLab accounts will have been created as
> > needed.
>
> GitLab allows forks and MRs by default, so 1 is effectively done.

That may be true in general, but empirically, it is *not* true of 
gitlab/gpsd/gpsd right now.  While signed in to GitLab, look at:

        https://gitlab.com/gpsd/gpsd

and note the absence of the Fork and Clone buttons.  Compare and contrast 
with:

        https://gitlab.com/NTPsec/ntpsec

If there's a fundamental conflict between "mirror mode" and Fork/Clone, 
then it might be necessary to turn off automatic mirroring to accomplish 
this.  Less than ideal, but probably tolerable.  Content could still be 
"mirrored" manually.

> All interested parties should do step 2 now.  Performing the
> command "git remote add upstream address@hidden:gpsd/gpsd.git"
> should accomplish this.

Not quite, since the idea is to also have a fork pointed to by 'origin', 
as well as a Savannah remote under some other name.  And being able to 
create a fork on GitLab is a prerequisite.

If it were possible to fork the GitLab gpsd repo now, I would have already 
updated my own repo accordingly.

> As for step 3,
>
>         Bernd Zeimetz <bzed>
> ?       Christian Gagneraud <ch_gans>
> ?       Chris Kuethe <ckuethe>
> ?       Ed Segall <ejs>
> ?       Eric S. Raymond <esr>
> ?       Fred Wright <fhgwright>
> ?       Gary E. Miller <garyemiller>
> ?       Greg Troxel <gdt>
> ?       Ian Bruene <j_von_random>
> ?       Mark McDonnell <magnolia_fan>
> ?       Reinhard Arlt <reinhardarlt>
> ?       Jon Schlueter <yazug>
>
> That's our Savannah developer list. Gary and I alread had GitLab
> identies and were enrolled to the project.  I've just enrolled Ian
> Bruene, Greg Troxel, and Christian Gagneraud.
>
> Anyone who is on this list and doesn't yet have a GitLab ID should
> make one and let me know what it is.

I'm on this list and I already have a GitLab account (same ID), but am not 
yet in the GitLab GPSD project.

> > --- The Actual Switch ---
> >
> > Step 4:  Announce the imminent switch.
> >
> > Step 5:  Turn off write access on Savannah.
> >
> > Step 6:  Initiate (or wait for) a final Savannah->GitLab sync.
> >
> > Step 7:  Turn on write access on GitLab.
> >
> > Step 8:  Announce the completion of the switch.
>
> I'm not sure 5 and 7 are actual steps. I don't know how to write-lock
> a repo at either site.  It is possible that the GitLab mirror is
> effectively locked by its status as a mirror, but I have not tested
> this.

The general idea is to transition across three states, to avoid 
inconsistencies:

1) Pushes are allowed to Savannah, but not GitLab.

2) Pushes aren't allowed at all.

3) Pushes are allowed to GitLab, but not Savannah.

I'm not sure it's possible to transition atomically from #1 to #3, hence 
#2, and in any case the "final sync" needs to happen between #1 and #3. 
I've certainly seen the temporary read-only mode used in other repo 
migrations, though admittedly not in the specific case of 
Savannah->GitLab, and I don't know the administrative details.

> Srep 5 should probably be replaced with "Turn off automatic mirroring
> on GitLab.

That's certainly something desirable at some point (and perhaps needed 
earlier if it affects the Fork/Clone issue), though as long as the 
mirroring is configured such that it doesn't rewrite history (i.e., 
fast-forward only), leaving it enabled somewhat longer would be harmless.

> In any case
>
> > --- After the Switch ---
> >
> > Step 9:  Devs remove the obsolete remote for Savannah.
>
> ...and probably want to change the name of the 'upstream' remote to 'origin'

No, the idea is that 'upstream' should point to the main GitLab repo and 
'origin' to one's own GitLab fork (both before and after).  The only 
difference between before and after is whether there's an additional 
remote for Savannah.

Devs with no intention of pushing commits prior to the switch, and who are 
content with any "mirror delays" on Gitlab, might not even bother with the 
Savannah remote in the updated setup.

> > > After this we can look at moving isses from the Subversion bugtracker.
> >
> > Did you mean Savannah bugtracker?
>
> Yes.  I glitched because Savannah knows how to make lpnks in its UI
> between its bugtracker and an associated Subversion repo. That's the
> one feature we lost when we moved to Git.

Yeah, that would presumably be regained by moving to the GitLab issue 
tracker.  MacPorts has had a similar problem since migrating to GitHub. 
It was determined that the GitHub issue tracker lacks some important 
features, so the tracker was left in place with 'trac'.  But ticket 
references now need full URLs, since the shorthand only works within 
GitHub.

Ideally the Savannah issue database could be migrated to GitLab, but I 
don't know if there are obstacles to that.  A complication is that if the 
GitLab issue tracker starts being used before the migration, then it would 
almost certainly result in issue number collisions (not to mention a loss 
of issue-number monotonicity).

If the shorthand used by Savannah just happens to match the shorthand used 
by GitLab, then that feature might even be regained with respect to 
existing references, without having to rewrite anything.  I'm not holding 
my breath, though. :-) And I don't think that fixing such references is 
important enough to justify rewriting the entire repo history.

Fred Wright