Would it be possible to migrate review comments from Gerrit into GitLab? I guess it would be kind of tricky, since you'd have to create closed merge requests based on patchsets in order to recreate the comments. And somehow also map commenters in Gerrit to users in GitLab. If it's not possible to migrate comments, it would be useful IMO to keep Gerrit in read-only mode so that past patchsets can be viewed. I've used past discussion on several year old patches to learn more about why something was done in a particular way, and it would be nice to preserve that ability.
Topic on Talk:Wikimedia Release Engineering Team/GitLab
Appearance
That's actually a pretty good point. I as well use gerrit in that way quite often. It's very educating to figure out why something was implemented in the way that it was, and while some times the commit message carries that information, it also quite often doesn't and that information is in the reviewers' comments. So I would love it if we could keep that knowledge around. Note btw that maintaining a read-only Gerrit will invariably be more expensive down the road in terms of maintenance so it's better to investigate early if it can happen
We thought a bit about importing, but, as you mention, that's a can of worms. Currently leaning towards moving projects toward read-only as migration progresses and eventually moving to a static dump of Gerrit review content.
Importing seems tricky because of the completely different process and assumptions. Just like we didn’t really import anything from the old SVN-era Special:Code and just left it as-is in a read only version, I think the same would be ok with gerrit. Converting gerrit to a static set of pages seems like a good way to reduce the maintenance burden.
Gerrit exposes review comments as git notes and they can be downloaded locally. While that doesn't really replace a web interface for ease of use, it is searchable, which can sometimes come in handy. (E.g. you can use Gerrit labels to tell who would be a good reviewer for a given piece of code.) It would be nice if that could be preserved in some form, too.
Ah, I remember you mentioned that before but had forgotten it. (For those interested, there are some notes on usage in the Gerrit advanced usage page and this blog post has more useful information about how it works.)
So, I think that would satisfy the case for merged patches, but ideally we could also preserve patches (and comments on patches) that are not closed -- there appear to be +5,300 of those.
Gerrit stores everything in the git repo in some way (e.g. you can see the comments on a given changeset with a command like git fetch "https://gerrit.wikimedia.org/r/mediawiki/extensions/GrowthExperiments" refs/changes/12/609212/meta && git checkout FETCH_HEAD
) so maybe that repo could be preserved independent of Gerrit.
It is possible to preserve refs/changes/*
. In GitLab these refs wouldn't be exposed via the UI since the refs/changes
namespace is a Gerrit concept, but those refs could be preserved in the repo.
Preserving refs/changes/*
and refs/notes/*
would be very worthwhile IMO.
Also, aside from directly looking at the repo history / blame, we have a lot of phab tickets containing links to gerrit patches, and we'd be dropping a lot of useful data if gerrit suddenly became inaccessible. Even just a separate static archive would still be a real pain if links broke without redirection.
Notably, the links from phab don't actually contain a useful reference to the commit, so if I see "Change 588935 merged by jenkins-bot" and the subject line of the commit, that's not an easy thing to map to the aforementioned git notes.
There are a few steps to map a change to review-notes:
refs/changes/35/588935/meta
is the discussion about change 588935 (https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/refs/changes/35/588935/meta).- From there you can find the sha1 of
refs/changes/35/588935/5
and find the review notes from there.