Hello,

At the end of the day, this is not impossible. The OpenJDK community has executed a full transition from custom Mercurial workflows (webrev et al.) to GitHub PRs -- but that transition includes a metric ton of automation which had to be written from scratch.

Hello,

Now, I am not a nay-sayer, but we have a sh*tload of things going and migrating it requires some serious man-power and for those uninitiated, I like to quote Thanh: "Getting Eclipse build where it is was a twelve month effort for three dedicated people" (IIRC). We no longer have Thanh and all his dedication and experience.

Hello,

I have used this quote when someone proposed moving to Gradle. Moving to GH workflows is harder.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Greetings,

Coming into this a little late.

On 8/9/22 13:58, Robert Varga wrote:
--<snip>--

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.

On 12/08/2022 19:30, Andrew Grimberg wrote:

Greetings,

Hello,

Coming into this a little late.

and welcome :)

On 8/9/22 13:58, Robert Varga wrote:

--<snip>--

1. Support for multiple branches
================================

[snip]

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? :)

On 8/12/22 13:10, Robert Varga wrote:

On 12/08/2022 19:30, Andrew Grimberg wrote:

Greetings,

Hello,

Coming into this a little late.

What is the paperwork we need to do to get this rolling? :)

As always, open a support ticket at https://support.linuxfoundation.org

Please be aware that this may take a bit to get working as we haven't set it up ourselves. My experience with it was testing out the workflow on GerritHub [0]. Since the folks that run GerritHub (GerritForge [1]) are the creators and maintainers of the plugin that allows for this workflow to even exist at present.
You can test out the workflow with some personal GitHub repos by logging into GerritHub.