Re: [gpsd-dev] Upcoming migration to GitLab

[Fred Wright]

On Sat, 25 May 2019, Eric S. Raymond wrote:
> 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.

So that should be done sooner rather than later.

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

There's nothing wrong with having both 'origin' and 'upstream', even if 
you typically push directky to 'upstream'.  If 'upstream' isn't the 
default push target for the branch, it just means you ahve to specify it 
explicitly.

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

Oh, it's *certainly* not necessary to resort to format-patch and am in any 
case.  One can always copy commits from one repo to another via fetch and 
push, with a rebase in between if needed.  No need to resort to 
error-prone and lossy patch files.

> > 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 was assuming that if some sort of migration mechanism is available, it 
would include the ability to set the "next issue number" beyond the 
imported issues.  In fact, there might be a way to set that parameter 
without the import.

On Sun, 26 May 2019, Eric S. Raymond wrote:
> Sanjeev Gupta <address@hidden>:

> > I do not seem to have even read access to this repo.

> Strange.  Can anyone else get at it?

No problem here:

MacPro:gpsd fw$ git fetch address@hidden:gpsd/gpsd.git master:test
> From gitlab.com:gpsd/gpsd
 * [new branch]          master     -> test
MacPro:gpsd fw$ git branch -D test
Deleted branch test (was c0a78c2d2).

But I don't see Sanjeev in the member list, which may even matter for 
reads (see below).

On Sun, 26 May 2019, Hal Murray wrote:

> address@hidden xxx]$ git clone address@hidden:gpsd/gpsd.git
> Cloning into 'gpsd'...
> > GitLab: You are not allowed to download code from this project.
> fatal: Could not read from remote repository.

I don't see you (Hal) in the member list, either.  I also don't see you in 
the developer list that Eric posted earlier, which is probably an error.

There's often a configuration option that determines whether "anonymous 
SSH" is allowed.  If it isn't, then the "address@hidden" spec only works with a 
valid SSH login from an allowed user.  Sometimes the "https://..."; form 
may work when the other doesn't, though this may also require a login in 
some cases.  E.g.:

MacPro:gpsd fw$ git fetch https://gitlab.com/gpsd/gpsd.git master:test
Username for 'https://gitlab.com': fhgwright
Password for 'https://address@hidden':
> From https://gitlab.com/gpsd/gpsd
 * [new branch]          master     -> test
MacPro:gpsd fw$ git branch -D test
Deleted branch test (was c0a78c2d2).

I expect that the intent is for this repo to be publicly readable, but 
that doesn't currently appear to be the case.  It seems somewhat unlikely 
that this property would be tied to "mirrorness", so perhaps the 
Fork/Clone issue isn't, either.

Fred Wright