I can weigh in a little bit on this. I'm not going to go in depth here,
but I can definitely answer a few of the questions raised.

On 2020-08-24 13:06, Robert Varga wrote:

Hello,

in today's (lightly advertised) TWS call, Casey raised the question of
migrating our infrastructure to GitLab in a bid to attract more
contributions.

Unfortunately a straight-up migration seems unfeasible to me due to a
multitude for things that come into play:

1) Jenkins integration, or are we saying we would also switch CI? If so,
how does that work with our JJB infra/CSIT?

I migration to GitLab would basically mean throwing the Jenkins infra
out the door and having to rebuild all jobs as GitLab pipelines.

Technically we could make MRs (GitLab's parlance of Merge Request vs
GitHub's of Pull Requests / PR) work in Jenkins, but we've not done any
work along that in that direction. We do, however, have PRs working with
Jenkins (I'll get more into this in a bit)

2) Patch review process. Let's not kid ourselves, GitLab and GitHub
patch review workflow is utterly different from Gerrit. I do not know
what the multi-branch support looks like these days, but last time I
checked GitHub's workflow was woefully inadequate to support multiple
concurrent streams (to test: do you have 'cherry-pick'-like option?)

To be brutally honest (and this it truly my personal opinion here) both
GitLab and GitHub suck when it comes to code review. The review process
that Gerrit pushes creates a much better experience IMO. It is, however,
a really huge hurdle for folks and a lot our time with new developers
seems to be spent on just getting them familiar with Gerrit Way

3) The straight-up choice of GitLab -- I think this is something the
community should have a choice in. Then again, we probably have far less
technical participation than would be needed to make a well-informed
decision.

For various reasons I'm not going to into the whys or wherefores of why
GitLab is the current preferred choice of LFIT for SaaS SCM/CI
solutions. I'll gladly talk to you off record on this one ;)

But to name just a few

* We have a way to enforce DCO requirements that stops changes from
coming in without them. GitHub is an after the fact CI validator which
makes it really hard to actually enforce and very easy to game

* GitLab supports repo hierarchies because of how they built their
system. GitHub is a flat namespace. We already flatten our repo
hierarchies (not that ODL has many, but it does have a few) by
translating the '/' to '-'. ONAP and other LFN properties already have
issues being able to really understand where a particular repo
originally came from in the GitHub mirror because of this flattening.

* GitLab CI is more flexible in that we can leverage pipeline templates
/ libraries. GitHub Actions is still lacking in this though they do have
the GitHub Actions marketplace, it makes it harder to have standard job
designs.

* GitLab CI allows us to do dynamic builders ala Jenkins as long as
we're doing it against AWS or GCE.

* It's possible with GitHub to do some amount of dynamic builders by
leveraging AWS CodeBuild but then you're splitting your GitHub Actions
into two logically distinct parts. The GHA workflow itself, and then the
CodeBuild "job" portion that runs out in a CodeBuild defined
environment. Each CodeBuild project has to be pre-created before it can
be used and we would essentially be back to having to come up with a
nice way (ala jjb) to manage those CodeBuild projects and their life
cycle :-/ (yes they can be managed from the aws cli, but we're still
then having to basically write a jjb type replacement that does stuff
agaisnt CodeBuild)

* One pro for GitHub that is a con for GitLab (not this affect ODL, but
it does affect some other LFN properties) EasyCLA support exists for
GitHub, it does not currently exist for GitLab.

With that out of the way, I would like to make a counter-proposal:

How about LF(N) investing some dev/test resources into making it
possible for outside contributors to be mirrored back to Gerrit?

Technically we can do this already. There is a GitHub plugin for Gerrit
that will allow us to create Gerrit side changes if a PR is opened a
GitHub repository. That being said, I've played with this workflow over
on GerritHub and it seriously hurts.

The workflow operates in the following manner:

* PR is created in GitHub

* For every commit in the PR a new Gerrit change is created

* If changes are requested on the PR then the modified code ends up
coming in as a _separate_ Gerrit Change. The requested changes are _not_
communicated back to the open PR, they happen internal to the Gerrit
system. If the system is configured to not send mail to unknown entities
(as all of ours are) then the person that raised the PR, if they have
never logged into the Gerrit system, will _not_ get notified.

* Once the change is merged on the Gerrit side, the code gets mirrored
back to GitHub but the PR does not get closed.

Additionally, and I don't know if this is just a limitation of how
GerritHub operates, the PRs don't automatically create Gerrit Changes.
You have to explicitly force a PR refresh cycle.

Now, some of this is obviously just a failing in how the plugin
operates, but the biggest issue here is that the GitHub/GitLab workflow
is very much an anti-pattern in Gerrit. Gerrit requires that Change-ID
to be able to track different patches across the life of a single
change. You don't get that in GitHub/GitLab, you just got a very messy
patch series to contend with.

I mean we already have a read-only mirror on GitHub for each and every
ODL mirror, and we should be able to make the same thing work on GitLab
(or any other force). We are utterly lacking the ability to review pull
requests -- in any way, shape or form!

What I mean is that while the repository mirrors are read-only, at least
GitHub provides API access, which should allow our infra to monitor
those repositories for incoming PRs. When a PR is created, updated,
closed, these actions should automagically be turned into equivalent
patch (series) being created in Gerrit. I do believe this is feasible,
as Gerrit provides a superset of required operations. It would also mean
any such PR would be serviced by our CI.

This would allow people to contribute, potentially provide Git{Hub,Lab}
reviews of PRs, extending the reach, while still not requiring any sort
of infrastructure or workflow migration. It also is very much aligned
with LF's mission to promote use of free software -- Gerrit is
(Apache-licensed) FOSS after all!

Hence, Casey, is this something LF has any capability/interest of
picking up in a bid to actively make the world a better place?

Regards,
Robert

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation