[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 https://gitlab.com/gpsd/gpsd 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 catb.org 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
Re: [gpsd-dev] Upcoming migration to GitLab, Lisandro Damián Nicanor Pérez Meyer, 2019/05/18
Re: [gpsd-dev] Upcoming migration to GitLab,
Fred Wright <=
Re: [gpsd-dev] Upcoming migration to GitLab, Eric S. Raymond, 2019/05/25
Re: [gpsd-dev] Upcoming migration to GitLab, Sanjeev Gupta, 2019/05/26
Re: [gpsd-dev] Upcoming migration to GitLab, Eric S. Raymond, 2019/05/26
Re: [gpsd-dev] Upcoming migration to GitLab, Gary E. Miller, 2019/05/26
Re: [gpsd-dev] Upcoming migration to GitLab, Hal Murray, 2019/05/26