[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Upcoming migration to GitLab

From: Fred Wright
Subject: Re: [gpsd-dev] Upcoming migration to GitLab
Date: Sat, 25 May 2019 15:48:31 -0700 (PDT)
User-agent: Alpine 2.21 (LRH 202 2017-01-01)

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

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:

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]