Topic on Talk:GitLab consultation

Would our switching away from gerrit for work involve us actually shutting down the gerrit instance at gerrit.wikimedia.org? If the plan is to just switch it to read-only, the rest of this comment can be ignored.

I ask because there's a lot of links out there to patches on our gerrit instance, and it'd be unfortunate if we just 404'd them all, particularly since they often contain useful discussions and context for how a particular changeset reached its final form.

You can fetch this information from the `refs/changes` part of the gerrit repo, so presumably at least that part of the repo could be preserved. That said, although the information is there it's not particularly usable to have to browse through JSON blobs in hidden metadata commits like this.

It seems like a useful requirement for this (or any other) switch would be a static dump of our existing gerrit instance for posterity.

Sorry, that was me. Forgot I had a fresh Chrome install so I'm not logged in anywhere. :D

Support for this. Gerrit links are all over the place, please let's not break them. Also all the comments on Gerrit changesets are valuable information that should be kept, pleaaaase. Mutante (talk) 23:53, 17 September 2020 (UTC)

All the Gerrit comments are stored directly into the git repository. I crafted an example for this reply, a couple inline comments in the web interface at https://gerrit.wikimedia.org/r/c/test/gerrit-ping/+/610907/1//COMMIT_MSG are stored as an entry under refs/changes/07/610907/meta which can be seen at https://gerrit.wikimedia.org/r/plugins/gitiles/test/gerrit-ping/+/17d1ffec299ff8284e7fdb80d55aa3ba70847d23%5E%21/

One could theorically just spawn Gerrit on their local machine and browse the change comment from there. Or potentially some utility could be rewritten just for that purpose.

As we did for the Bugzilla to Phabricator migration, it is surely possible to extract all those comments from Gerrit and reproduce them as merge requests in Gitlab. For URL it might not be as trivial though, since a Gerrit change number / patchset would not translate 1/1 to a Gitlab merge request id :-\ If we migrate to Gitlab, most probably we would keep a read-only Gerrit instance just for the purpose of easily accessing history, much like we are still keeping around our old codereview tool: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/statuschanges

We are actually working to undeploy the CodeReview extension: https://phabricator.wikimedia.org/T116948

We've done a dump of the data and are waiting on url redirects: https://phabricator.wikimedia.org/T205361

https://static-codereview.wikimedia.org/MediaWiki/1212.html

So, doing something similar for Gerrit seems reasonable (a static dump of a crawl of Gerrit, with url rewrites).

My concern was that this would be considered too much work / too hard (as you already said for URL it's not trivial) and in the end it wouldn't happen. But if that's not the case and existing URLs will keep working that's great.

I would agree, keeping links working to a static copy (as was done bugzilla back when) or somesuch would be very valuable. Especially as tasks/patchsets can linger here for a long time and then actually bubble up and get worked on.

One of the trickier parts is partial change IDs - those are used quite a bit in commit summaries (like this). Would be nice if those could keep working.