Open kutschke opened 5 months ago
gaponenko
commented
5 months ago I would minimize the extra work and stay with the system version. If and when git adds a compelling new feature, and that feature is missing in the system version, we can switch to a CSAID or Mu2e-maintained install.
kutschke
commented
5 months ago From Seth Graham:
Our support for git is "we install whatever the OS provides." RHEL does not to do major version updates within an OS release, so the /usr/bin/git available now will remain about the same for RHEL9's entire lifecycle. It will get bug fixes and security updates backported to it.
So if you need to change versions more often than that.. you should probably continue to use the version in cvmfs.
This sounds definitive. The OS people do not plan to keep git up to date, end of story.
brownd1978
commented
5 months ago I would wait to change source until the version in spack is at least as recent as the version provided by the OS.
On Mon, Jun 24, 2024 at 9:42 AM Rob Kutschke @.***> wrote:
From Seth Graham:
Our support for git is "we install whatever the OS provides." RHEL does not to do major version updates within an OS release, so the /usr/bin/git available now will remain about the same for RHEL9's entire lifecycle. It will get bug fixes and security updates backported to it.
So if you need to change versions more often than that.. you should probably continue to use the version in cvmfs.
This sounds definitive. The OS people do not plan to keep git up to date, end of story.
— Reply to this email directly, view it on GitHub https://github.com/Mu2e/Muse/issues/110#issuecomment-2186989203, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAH572D53TDLZWHIRGZA5DZJBD7HAVCNFSM6AAAAABJ2BCRQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWHE4DSMRQGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- David Brown @.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720
kutschke
commented
5 months ago I would wait to change source until the version in spack is at least as recent as the version provided by the OS.
Yes. I think we all agree on that
After discussing with Kyle and Marc, I have opened an issue in a CSAID issue tracker to discuss this and other products that we used to get via UPS, suchs as gitflow, gdb, valgrind ... . Let's mostly move this conversation to that issue
https://github.com/FNALssi/spack-at-fnal/issues/2We can use the current issue if we want to discuss some things in house before presenting a consensus to Kyle and Marc.
There is no rush on this - it's a question of how to avoid git atrophy with time.
On the SL7 GPVM nodes the system git was ancient, v1.8.3.1. That was OK since we got an up-to-date git from UPS. We did the UPS setup in mu2einit.
On AL9 the system git is 2.43.0, which fairly recent. We are not currently loading a version of git in our spack view. As it happens the most recent version in /cvmfs/mu2e.opensciencegrid.org/packages/git is 2.40.0, so a little older than the system.
We should decide what we want moving forward. Do we want CSAID to keep the system git reasonably up to date? Or do we want to include it in our spack view? Do we want to make this decision together with the online group or on our own?
When discussing this, do we need to consider control over the timing of new git releases and the possibility of the need for a rollback? We could decide that git is mature enough that we can ignore this. In that case, asking the system people to do it is the least work for us.
I don't know what the AL9 people at the lab intend to do with versions of the system git moving forward. I have put in a ticket to learn about it RITM2140247 .