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

--<snip>--

1. Support for multiple branches
================================
It is OpenDaylight policy to support up to 3 branches at any given time for any MSI project. For MRI projects, that number gets to 4 for periods last 2-5 months -- as is the case for YANG tools right now, we have:
- yangtools-7.0.x for 2022.03 Phosphorus security support
- yangtools-8.0.x for 2022.06 Sulfur
- yangtools-9.0.x for 2022.09 Chlorine
- yangtools-master for 2023.03 Argon
As far as I know, Github does not provide the equivalent of Gerrit cherry-picks out of the box. That certainly was the case ~5 years when I investigated this more deeply.
The crux of the issue seems to be Change-ID and its tie-in with GH PRs. I was told by Andy Grimberg this is nigh impossible to reconcile. Change-ID is critical for cross-referencing commits, because equivalent patches can look very differently on each supported branch.
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.

2. Permissions
==============
Github is a system external to LF. As such, I do not think there is infrastructure present to project each project's INFO.yaml into Github permissions. AFAICT the only existing thing is the 'OpenDaylight project', which is an all-or-nothing thing. That is something LF IT has to tackle before we consider migrating.

Technically, we have something comprable on the GitHub side using INFO.yaml. However, absolutely no project that we support in GitHub has elected to utilize it as it ended up being harder to work with than the INFO files as they currently exist in repo. Mostly because the implementation pulled it out of the repos themselves and stuck it into a side repo inside the Org. The reasons for this are varied but mostly come down to how easy it was to detect changes to the remote INFO files that needed to be then be shadowed into the LF's releng/info-master repository.

3. Verification
===============
Our current infrastructure is tied to Jenkins. A switch to GH requires that a PR triggers the appropriate jobs in Jenkins. Unless we are talking a straight-up move to GH Actions, we need point 1. to be solved and drive verification projected from Gerrit back to GH. If GH actions are in the picture, at least maven-verify need to be migrated. Again, this needs a community contribution.

LF managed Jenkins already supports GitHub as a source SCM triggering into Jenkins. In point of fact all of the global-jjb core jobs that ODL utilizes have two variants, a Gerrit variant and a GitHub variant. The primary issue being that you can't have both variants active for a given repository at the same time because namespace collisions.

There was an idea floated not long ago internally about if it would be possible to sort of go the other way Gerrit -> GitHub with work still primarily happening in Gerrit (changes raised, etc) but cause Gerrit changes to raise PRs into the GitHub mirror to then trigger GitHub Actions that would then somehow have the results shuttled back to the Gerrit Change.

I believe this would be doable, but nobody has had the time to sit down and evaluate how to actually make it work.

The best scenario would be that changes could be raised on either side (Gerrit or GitHub) and that review itself would just continue to happen in Gerrit along with the final merges. Getting bi-directionality would be a major project though.

--<snip>--

-Andy-

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation

NOTICE: The Linux Foundation supports their employees with flexible work
hours. If you recieve mail from me outside of standard business hours
please be aware that I do not expect a response until the next standard
business day.