Tagging all zvbi maintainers so they are aware of the issue:
@jwrdegoede @buc @mchehab

I thought there was only one commit, but there are 2:
- https://src.fedoraproject.org/rpms/zvbi/c/8dfc5d796d0a6070f54b99ee03189b173d41d5df?branch=epel10
- https://src.fedoraproject.org/rpms/zvbi/c/339b14f98660b2d9ee7b0832eee8a702b4a4c880?branch=epel10

There was also a failed build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=123262011

The failed build may induce the need for a release bump. Not sure about that...

There is a way to address this with git that doesn't require deleting branches, but it's a bit awkward. I call it a double merge.

git switch epel10
git merge f40
git switch f40
git merge epel10

That will put epel10 and f40 on the same merge commit. It would diverge epel10/f40 from rawhide/f41, preventing future fast-forward merges, but since rawhide/f41 just has a rebuild commit, this can be worked around by cherry-picking the latest rawhide commit to epel10 and then doing the double merge with rawhide.

Carl's magic seems strong, does releng have stronger magic ? ;-)
Joke apart, I'll keep Carl's solution as second best choice, and would prefer a clean branch and history from the start, if possible at all.

It's possible to do it but I don't think it adheres to the policy.

Historically we did not allow to remove git branches in dist-git repository, but FESCo recently approved their removal *if and only if* all the commits in the branch to be deleted can be reached from another branch.

https://docs.fedoraproject.org/en-US/infra/releng_misc_guide/sop_remote_dist_git_branches/

@kevin @jnsamyak What do you think?

Yes, I know the request is quite borderline, but the full quote is:

Historically we did not allow to remove git branches in dist-git repository, but FESCo recently approved their removal if and only if all the commits in the branch to be deleted can be reached from another branch. This is a requirement to ensure that if any of the commits were used in a build, we still have the commit accessible and thus we are able to reproduce the build if needed.

The 2nd sentence explains the reason not to delete a branch, that is to be able to reproduce the build.
in this case, no successful build has been done from any of the 2 commits. So my reading would be we're in an acceptable case here.

How exactly would you like the git history to look like for the EPEL10 branch? [1]
I only see 3 commits, the first of which was made 18 years ago. If I understand correctly, you would like to get rid of the 2 commits that were made 2 days ago?

[1] https://src.fedoraproject.org/rpms/zvbi/commits/epel10

If the epel10 branch could be rebased to be exactly like rawhide, that would be just perfect.
Alternatively if the 2 commits in epel10 could be dropped, I can take care of the rebase to rawhide.

I may get pelted by rotten fruit for this, but...
Would it not be possible to rebase the EPEL10 commits on top of rawhide locally and then force push straight to the EPEL10 branch?
You should have the appropriate permissions and I don't think the branch is protected. It will mess with other people's local git histories, however.

No worries, I may get my share of rotten fruits on my beautiful face for asking this too ;-)
I don't think git would let me force-push, but yeah, that what I'd have done. My hope is releng people have more power and are allowed to force-push.
I don't think anybody else than the maintainer that pushed the faulty commits and me have pulled from the epel10 branch though and we can probably both live with it. The purpose is to fix an unfortunate mistake that has been done in good faith.

A benefit of the double merge method I suggested is that git history is not rewritten, so anyone that has cloned the repo just has to do a git pull.

The 2nd sentence explains the reason not to delete a branch, that is to be able to reproduce the build. in this case, no successful build has been done from any of the 2 commits. So my reading would be we're in an acceptable case here.

Alright, I inquired some more and it seems you are right. A script [1] can be run to check if the branch is safe to delete and it seems like it can.

However I cannot do it, you are going to need a member of the sysadmin-main FAS group.

@jnsamyak Could you take a look, please? It's at your discretion. There is always the double merge method...

[1] https://pagure.io/releng/blob/main/f/scripts/distgit-branch-unused.py

Edit: To be clear the script didn't finish for me. However, it got to No builds found in koji for branch epel10 before it failed.

Branches matching this regex: https://pagure.io/releng/blob/main/f/scripts/distgit-branch-unused.py#_57 ^(f\d{1,2}|el\d|epel\d|epel1\d)$ are not allowed to be deleted. The policy, as approved by FESCo when I was still on it, explicitly forbids the removal of "normal" branches, such as f41, epel10, rawhide.

The policy allows accidental "feature" branches to be removed. It was not designed to clear git history when somebody pushes undesired content.

Fun, another regex to fix for EPEL 10 minor versions :grinning:

From what I gathered, here are a few potential approaches based on our conversation:

1. Double Merge Solution: As suggested by Carl, using a double merge might allow us to synchronize epel10 with f40 without losing commit history. Since, deleting the branch is not allowed as per the FESCO guidelines.

2. Rebase or Commit Adjustment: If feasible, rebasing epel10 onto a state that matches rawhide or selectively dropping non-essential commits might streamline the branch without breaching build integrity or historical relevance.

3. Sysadmin Powers: Considering the restrictions on force pushes and branch deletions, I'll coordinate with the sysadmin team to understand if permissible administrative actions can be taken under the current policies.

I plan to bring this up for a more detailed discussion during the next releng call on Tuesday next week to explore these options further and decide on the best course of action. This will help ensure that whatever approach we take is in line with FESCo guidelines and facilitates the long-term maintenance of the epel10 branch.

Checking package zvbi in /home/jnsamyak/work/zvbi
Found branch epel10 in bodhi with tags: epel10.0, epel10.0, epel10.0-testing, epel10.0-testing-candidate, epel10.0-signing-pending, epel10.0-testing-pending, epel10.0-pending, epel10.0-override
Checking for zvbi in tag epel10.0... (no)
Checking for zvbi in tag epel10.0... (no)
Checking for zvbi in tag epel10.0-testing... (no)
Checking for zvbi in tag epel10.0-testing-candidate... (no)
Checking for zvbi in tag epel10.0-signing-pending... (no)
Checking for zvbi in tag epel10.0-testing-pending... (no)
Checking for zvbi in tag epel10.0-pending... (no)
Checking for zvbi in tag epel10.0-override... (no)
No builds found in koji for branch epel10

I think the branch is safe to delete, I can try looking at it more tomorrow once, and will proceed to delete it, so folks can request a fresh branch as per the process.

hey @xavierb, can you try requesting a new epel10 branch now?

I was able to request a branch, which now shares the same history as rawhide, and zvbi is built for EPEL 10.
Thanks @jnsamyak :-)