On 12/08/2022 19:30, Andrew Grimberg wrote:
Coming into this a little late.
and welcome :)
On 8/9/22 13:58, Robert Varga wrote:
1. Support for multiple branches
That having been said, I do believe this is fixable by automation, e.g. having a bot assign Change-IDs for a PR and squashing each PR into a single patch -- which then can be projected to Gerrit, allowing for migration. I am not aware of such a bot existing, so I track this as something would have to be contributed.This is still accurate AFAIK. Change-ID is very much a Gerrit concept which they leverage heavily to understand the status of any given change across the status of all branches.
That all being said, there is the ability to pull GitHub PRs into Gerrit. The problem with this being as follows:
1. It's a manual process by way of a plugin in Gerrit that has to be initiated by someone that is expectings a PR that needs to come in.
2. Change-ID isn't something that is enforced by GitHub, it could be semi-enforced by a GitHub Action, but all that would do is mark the PR as not passing, so it's not true enforcement. GitLab, on the other hand, _could_ enforce this because it's possible to setup a regex filter on commit messages that must be passed to even raise an MR, but there's other downsides to that (including LFRE not having any job integration currently with GitLab and Jenkins, though it's possible).
Doing the Change-ID work by a GitHub Action or bot may be a solution for reflecting changes back into Gerrit, but you're still going to run into some weird edge cases.
I think getting PRs into Gerrit would be a very useful first step. If there is genuine interest, we should see the facility get used for contributions -- and we can hash things out and we use it.
What is the paperwork we need to do to get this rolling? :)