[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: Sun, 26 May 2019 17:33:13 -0700 (PDT)
User-agent: Alpine 2.21 (LRH 202 2017-01-01)

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:

and note the absence of the Fork and Clone buttons.  Compare and contrast

Ah, OK. We *are* going to have to turn off mitroring before it can be forked, 
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
 * [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 master:test
Username for '': fhgwright
Password for 'https://address@hidden':
 * [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

reply via email to

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