gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Upcoming migration to GitLab


From: Eric S. Raymond
Subject: Re: [gpsd-dev] Upcoming migration to GitLab
Date: Sat, 25 May 2019 21:06:34 -0400
User-agent: Mutt/1.10.1 (2018-07-13)

Fred Wright <address@hidden>:
>> 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

Ah, OK. We *are* going to have to turn off mitroring before it can be forked, 
then.
I didn't know that - haven't done this before.

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

Yes, I guess it is. I pointed mine at master of the main repo,
which we won't in general want people to do. Gary should, though.  
We don't want the bus factor on that role to be 1.

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

I just fixed that.

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

And I think we've now confirmed that it *is* effectively locked.

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

I don't either. But I'm not worried about it. We don't get enough pushes per
day that transplanting in-between ones fromSavannah to GitLab by hand using 
git patch-format and git am is going to be at all difficult.

> > 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),

I'm now pretty sure those things are tied together.

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

Again, I'm not worried about this. New issue numbering will start at #1.
We're not going to start colliding with open-issue numbers from Savannah
before the switchover is complete.  There's no way to avoid having new GitLab
issue numbers coincide with those on very old closed issues from Savannah,
so the best we can do is have a commit documenting the transition that
explains the problem.

I'll do a pass over the bugtracker to see if there are issues we can retire
to simplify matters.  We might end up with few enough left that the right
thing to do is just file copies by hand - especially since bug-reporter
identities are unlikely to transplant.
 
> 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.

It isn't, and I agree, it isn't.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>





reply via email to

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