#11475 Create ELN branches for two packages
Closed: It's all good a year ago by yselkowitz. Opened 2 years ago by yselkowitz.

  • Describe the issue
    In preparation for the forthcoming import of CentOS Stream 10 from ELN, I have been preparing PRs to minimize unwanted build dependencies from ELN packages. Rust-based packages are one area where RHEL/ELN differ significantly from Fedora, and as such the RHEL/ELN changes are in some cases being maintained in ELN branches rather than Rawhide, with mutual agreement of the ELN and Rust SIGs.

The following two PRs have not been merged into rawhide but the maintainer has also not created the requisite branch for either them or us to maintain them there, and neither the ELN nor Rust SIGs have admin privs to create them:

https://src.fedoraproject.org/rpms/clevis-pin-tpm2/pull-request/1
https://src.fedoraproject.org/rpms/virtiofsd/pull-request/2

Therefore, please run fedpkg request-branch eln --sl rawhide:2099-12-01 --no-auto-module in rpms/clevis-pin-tpm2 and rpms/virtiofsd so that these changes can be maintained there in the meantime, and the 400+ unwanted rust crates they currently pull in can be dropped from the ELN buildroot.

  • When do you need this? (YYYY/MM/DD)
    ASAP. The pre-import ELN mass rebuild is due to begin on 26th June, but we need new builds well before that in order to assure that no other packages are pulling rust crate packages in the buildroot.

  • If we cannot complete your request, what is the impact?
    400+ unwanted rust crate packages will be imported into CentOS Stream 10 that will then have to be retired.


It seems that is not as simple, we currently do not have an override function for requesting branches, and I would rather not do such invasive action as adding myself as package admin...

It also looks like the clevis changes might get merged upstream. If there is no reaction on the linked PRs I will create the branches myself on 2023-06-15

Metadata Update from @humaton:
- Issue tagged with: high-gain, medium-trouble, ops

2 years ago

Who maintains the eln branch when it is forcefully created this way?

I think we need to treat this as equivalent to requesting to maintain an EPEL branch.

virtiofsd was branched, so that leaves just clevis-pin-tpm2.

Please add https://src.fedoraproject.org/rpms/fido-device-onboard/pull-request/1 to this request, as the maintainer is the same as clevis-pin-tpm2.

It's been a week, can we move forward with these please?

Who maintains the eln branch when it is forcefully created this way?

still hasn't been answered.

I think we need to treat this as equivalent to requesting to maintain an EPEL branch.

^^^ This is being documented by the ELN SIG.

Please don't for clevis-pin-tpm2, we are working on the problem, the team would like less work not more!

I think we need to treat this as equivalent to requesting to maintain an EPEL branch.

The Stalled EPEL Request process is an established policy that involves filling a Bugzilla, waiting three weeks, and then the maintainer is assigned to the package and takes responsibility for maintaining the branch.

I feel that ELN is working in a silo and filling large amounts of PRs to disable tests or vendor libraries, merging things with provenpackager privileges, and asking releng to override maintainers without an established policy in place, all without adding more RHEL peoplepower to maintain the packages in Fedora.

The requested changes have been merged, so I'll close this. However, in the future, the ELN SIG must be by definition the final arbiter of ELN branches and tags, and any such future requests fulfilled in line with that.

Metadata Update from @yselkowitz:
- Issue close_status updated to: It's all good
- Issue status updated to: Closed (was: Open)

a year ago

However, in the future, the ELN SIG must be by definition the final arbiter of ELN branches and tags, and any such future requests fulfilled in line with that.

I am sorry, but this seems like "ELN is ours, we don't bother with policies" -- and I am not happy about that. Please work with FESCo to create actual rules to follow.

The use of the term arbitrator there was definitely an accidental overstatement.

What was intended is that the creation of a separate ELN branch needs to be communicated to the ELN team in order for us to ensure that our rebuild automation doesn't continue to rebuild from the Rawhide branch. Otherwise, we're causing problems for both ELN and the packager and no one wants that.

Obviously, the creation of a separate ELN branch needs to be communicated to the ELN SIG when it is the package maintainer who desires this.

However, this is the other way around: here the ELN SIG requests a separate ELN branch -- and if the desire is to follow the EPEL policy for stalled requests, it should be codified and followed. Instead the branch was requested with no plan to track responsibilities.

Log in to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog