[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: Fri, 24 May 2019 15:23:39 -0700 (PDT)
User-agent: Alpine 2.21 (LRH 202 2017-01-01)

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

We have a plan to fix this.  It's to gradually migrate the project to
hosting on GitLab and use GitLab pages for the Web stuff, installing a
redirect at my personal site.

Long overdue IMO. An important benefit (as has already been pointed out) is to support contributions via merge request, instead of the tedious and error-prone patch-via-email approach.

A while back, Savannah had gotten ill, and there was somewhat of a mad panic to move GPSD to another hosting site, but then Savannah fixed their problem and the panic ended. Nevertheless, migrating at a time when Savannah is healthy avoids the whole panic thing.

There are some pros and cons of GitHub vs. GitLab, but none is terribly strong, so if GitLab has been chosen, so be it.

This will involve the following initial steps:

Step 1: The GitLab mirror at stops
being a mirror and becomes the official repo.  Devs will need to
have GitLab accounts and to do this:

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. Whenever a change is sufficiently complex and/or sufficiently controversial, it's a good idea to have some form of code review, and the MR mechanism provides a reasonable framework for doing so. Just because someone *can* push a change directly without review doesn't always mean that they *should*.

Thus, even devs with direct write access should still have personal forks of the main repo to use for MR purposes. So, assuming the usual naming conventions:

1) 'origin' would point to the individual fork on GitLab.

2) 'upstream' would point to the main repo on GitLab.

It's also (almost, see below) possible to use this setup right away, by simply including a third remote pointing at the Savannah repo.

It would be a good idea for devs to update to this configuration now, in advance of the switch, but the current gitlab/gpsd/gpsd lacks the 'Fork' and 'Clone' buttons. Granted, the 'Clone' button is just a convenience for copying the repo URL to the clipboard, but the 'Fork' button performs a real function. And manually constructing what I believe to be the correct "new fork" URL just gives a 404.

Interestingly enough, there seems to be a gitlab/NTPsec/gpsd repo which is itself a fork of gitlab/gpsd/gpsd, even though creating new forks of the latter doesn't seem to be possible. I'm not sure what the purpose of NTPsec/gpsd is, though I suspect that it will be obsolete after the transition. A group-owned fork doesn't make a lot of sense, since MRs normally come from individuals.

The NTPsec/gpsd repo is itself forkable, though it would probably just confuse things to use it a a basis for forks that should really be children of gpsd/gpsd, rather than its grandchildren.

So I think the repo portion of the migration (ignoring the website stuff) should look like:

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

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

--- After the Switch ---

Step 9:  Devs remove the obsolete remote for Savannah.

Step 2: I set up the CI job to publish the website to GitLab pages
on each commit.

Step 3: I install a redirect from my site on ibiblio.

There probably needs to be an update on as well.

After this we can look at moving isses from the Subversion bugtracker.

Did you mean Savannah bugtracker?

Tentative date for Step 1 is June 1st.

That doesn't seem unreasonable, but getting the "before" steps done ASAP would avoid a big scramble at the switchover time.

Fred Wright

reply via email to

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