@Cédric, OPNFV is mention in this thread ...

Olivier

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:

    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?


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
    decision.


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 (http://gerrithub.io/) 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
system.

-Andy-

    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?

    Regards,
    Robert

--

 

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

 

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@...

_________________________________________________________________________________________________________________________

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.