Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to use our own fork of rivet #5373

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Move to use our own fork of rivet #5373

wants to merge 1 commit into from

Conversation

ktf
Copy link
Member

@ktf ktf commented Mar 1, 2024

No description provided.

@ktf ktf requested a review from a team as a code owner March 1, 2024 08:40
@maireiphc
Copy link
Contributor

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.

  1. 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 ?
  2. For PAG-MC, I am wondering whether the workflow (upgrade, user merge request/pull requests) will change...
  3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants