Move to use our own fork of rivet

[ktf]

No description provided.

[maireiphc]

Hello @ktf (@pzhristov , @jackal1-66 )

I have just noticed this open Pull Request on this change to the rivet recipe, pointing tentatively to a fork of official Rivet repo.

One question from me:
you point to https://gitlab.com/alisw/rivet and not to https://github.com/alisw/rivet.
You seem to have created this gitlab fork, thi is the only example existing under gitlab/alisw...

I suppose this is motivated by the fact that the official Rivet repo is under gitlab and not github ?

1. Is it really easier to MR say a Rivet analysis from ALICE to the official repo among 2 gitlab forks (likely yes) ? Conversely, how painful a MR could be from a GitHub repo ? (so far, @jackal1-66 does it ... manually ? 4 files to copy in MR per rivet analysis)
2. Is it maybe also much easier to bump from one Rivet version to the next starting from a same environment (gitlab) ?

We actually have our own alice repository for Rivet,
But it is under github.
we have functioned from this up to v3.1.6 of Rivet, it is only after Christian Holm investigated recently the thing and updated the recipe alidist/rivet.sh that we manage to point back to the official repo, the only version tested with this worflow has been v3.1.8, the current version in AliGenerators.

4. From the ALICE Computing team point of view, what would be best ? Force us to stay with github ecosystems (to be consistent with most of our ALICE forks, habits, Pull Requests, ...) or is it transparent for you either option is the same ?
5. For PAG-MC, I am wondering whether the workflow (upgrade, user merge request/pull requests) will change...
6. This poses further the question of who may own the gitlab alisw/rivet fork (so far PAG-MC owns primarily the github one, S&C team owns it as well as second line of defense and assistance)

Looking for your opinion.