Re: [gpsd-dev] Upcoming migration to GitLab

[Eric S. Raymond]

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.

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

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.

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

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

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'

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

That's it.

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

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

Yes.  
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>