Re: Widening reach for ... code?

Andrew Grimberg

On 2020-08-24 13:48, Thanh ha wrote:
See inline.

(Include's Robert's fixes)

On Mon, Aug 24, 2020 at 4:06 PM Robert Varga <nite@...
<mailto:nite@...>> wrote:


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

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?

Either way would require modifying JJB to support the new SCM system
GitLab and the trigger mechanism would be quite a bit different than
what we have with Gerrit (PRs vs Gerrit Trigger) so this wouldn't be a
simple change of backends. Concern here for me is who would lead this
effort. I think we'd need LF support considering the community does not
have the available cycles to do this.

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

The cherry-pick option in GitHub (likely GitLab too but I'm not familiar
with it) is CLI with a command like `git cherry-pick master` or similar.
Personally I like this method but that's because I'm in the weeds of Git
often, I can see the value in an easy button for this like Gerrit has.

Sadly, the GitHub / GitLab model is via PRs (basically branches) which
are not equivalent to patch reviews like Gerrit. So a change of system
would require all the committers to unlearn Gerrit.

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

I think this would be better received if the LF did the background work
to make this work for the community, however I feel LF is no longer
actively engaged in LFN project's day to day development cycle. Meaning
LF is going to drop GitLab on us and tell us to do the legwork to make
all of our projects work with that. This kind of transition would
require a significant amount of work for the community to take on to
transition the CI bits and adjust our workflows. Considering there's a
lack of people to lead this kind of work... I worry that this is an
exercise in frustration.
We are doing some leg work on this. We've been getting semi-deep in the
weeds the following of late:

GitHub + Azure Pipelines
GitHub + Jenkins (we already support several projects in this config)
GitHub + GitHub Actions
GitLab + GitLab CI

You'll note a distinct lack of GitLab + Jenkins in that list ;)

OPNFV had a proposal just last week for an RE managed lift from Gerrit +
Jenkins -> GitLab + GitLab CI transition. The reason they were targetted
is because they don't really have that many jobs to transition and in
all honesty, it wouldn't be much of a change in how they do things now
outside of the use of GitLab instead of Gerrit. The reason being that
most of the work in OPNFV actually happens in third-party CI systems.

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 contributions to be mirrored back to Gerrit?

This is possible as I've used GerritHub ( before
and it worked (although over 8 years ago when I tried it), it was quite
clunky but maybe it's better now. I'm not sure if GerritHub is
proprietary or if there's available a Gerrit plugin for this feature.
Not sure how hard it would be to replicate this feature but at least it
seems to be possible.
No, it's still clunky and nasty IMO. That's me having just tried it
again about 1.5 - 2 months ago. The plugin that GerritHub uses is
available to us, but I've not tried using it directly, just via their


I mean we already have a read-only mirror on GitHub for each and every
ODL project, 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?


Andrew J Grimberg
Manager Release Engineering
The Linux Foundation

Join to automatically receive all group messages.