Packages that only require git binary should depend on git-core and not on the git package.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.
Why not have the packages that require the git executable carry:
BuildRequires: /usr/bin/git
?
That'd probably be simpler.
Aslo, the "Scope" is a bit unclear to me, and it's also not filled in the Change proposal template: https://fedoraproject.org/wiki/Changes/ChangeToGitCore#Scope
The Change says "The proposed change would be to open Pull Requests against each package to switch to git-core and, when possible, test it before the PR is accepted.", so I assume the Change owner would open those PRs, but other than that, who is actually supposed to verify whether git or git-core is necessary, merge the PR, and build the package? If that's supposed to be done by those packages' maintainers, that should be explicit in the proposal, IMO.
git
git-core
-1
At the end of the day, there are much better ways to do this than to try to mass-change packages and discover that some of them really do need more than git-core.
As the Change Owner, I want to explain my intentions about the SelfContained Change Proposal. My initial explanation could have been clearer, and I appreciate the feedback. This is my first time with this process, and I am still learning how to do it correctly.
My original idea was to personally test the proposed change on each of the listed packages to determine whether switching to git-core or BuildRequires: /usr/bin/git would be feasible without breaking package builds or usage. Only after verifying compatibility, I would open a pull request (PR) for each affected package. The intention was never to execute a mass change all at once but rather to work collaboratively with package maintainers, relying on their review and approval for each PR.
While it is true that I could pursue this change without submitting a Change Proposal, I believed it would be more transparent and beneficial to document the rationale as a SelfContained Change. Linking the Change Proposal to each PR would provide context and clarity to maintainers about the motivation behind the change. Furthermore, using the Change process would offer a structured way to track progress and monitor which packages have been updated and which have not.
Metadata Update from @ngompa: - Issue tagged with: self contained change
Metadata Update from @ngompa: - Issue set to the milestone: Fedora Linux 42
+1
But, please please fill out the Scope section as discussed above so that people know what to expect.
I'm voting +1 even though the scope is partially unclear, because I think it ultimately the details of implementation aren't that important and can be figured out in the process. Out of all those packages listed, 99+% will be fine with just git-core. We may end up with some packages and maintainers using one form, and others another, but that's fine. We'll get the benefits of a faster and leaner build either way. And to answer @sgallagh's comment, even if it turns out that some package needs full git and we don't immediately notice this, it'll be trivial to fix.
Metadata Update from @zbyszek: - Issue untagged with: self contained change - Issue set to the milestone: None (was: Fedora Linux 42)
Updated the Change wiki page with clarified scope.
https://fedoraproject.org/wiki/Changes/ChangeToGitCore#Scope
Thanks.
(I have no idea what happened above. I didn't intentionally change any metadata.)
Metadata Update from @zbyszek: - Issue set to the milestone: Fedora Linux 42 - Issue tagged with: self contained change
I agree with @zbyszek. Also, I would expect that, in the majority of cases, it would be immediately obvious if the full git was expected.
Metadata Update from @sgallagh: - Issue tagged with: meeting
This ticket will be discussed at the 2025-01-14 meeting.
This was approved at the 14th meeting with:
Change is approved with the clarification that a proven packager will merge all the pull requests which remain unanswered after 4 weeks. (+6, 0, -0)
Metadata Update from @kevin: - Issue untagged with: meeting - Issue tagged with: pending announcement
Announced.
Metadata Update from @kevin: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.