#2544 provenpackager request for carlwgeorge
Closed: Accepted by churchyard. Opened by carlwgeorge.

I would like to be added to the provenpackager group. I am a member of the CentOS team (building CentOS Stream) and the EPEL steering committee. At the intersection of these roles, I am working on the EPEL Next proposal. There are two distinct reasons I am asking for provenpackager permissions.

  1. Some EPEL packages will require rebuilds (with a release bump) in EPEL Next to be compatible with CentOS Stream. There are ten of these we currently know about in EPEL8. Between future library changes in CentOS Stream and new packages being added to EPEL, I expect this number to grow over time. I would like to be able to trigger these rebuilds without waiting for the maintainer to quickly resolve installation failures.

  2. Due to the nature of my role building CentOS Stream, I find out about new RHEL packages (planned for the next minor release) very early. If I notice those packages in EPEL, I proactively file bugs to let the maintainer know that the package will need to be retired per policy at the next minor release of RHEL. I would like to be able to retire these packages myself (after that minor release) if the maintainer doesn't respond in a reasonable amount of time.


+1

(Instead of (just) voting, we are supposed to announce this to sponsors...)

Metadata Update from @churchyard:
- Issue tagged with: provenpackager

Announced.

I'm +1

Side note about retiring packages: When we added python3 to RHEL 7.7 and retired python36 from EPEL, we got a lot of bug reports by CentOS Linux users. At the end, we needed to unretire it until CentOS 7.7 went out. Please take that in mind and don't retire the packages too early.

+1

Thanks for all your hard work!

Side note about retiring packages: When we added python3 to RHEL 7.7 and retired python36 from EPEL, we got a lot of bug reports by CentOS Linux users. At the end, we needed to unretire it until CentOS 7.7 went out. Please take that in mind and don't retire the packages too early.

Absolutely, I remember this vividly. What I had in mind was the packages I filed bugs for with the 8.2 release that still have not been retired after the 8.3 release. That's more than enough time for CentOS Linux and any other rebuilds to catch up. I can bring this up at the next EPEL steering committee meeting to see if we want to formalize on a standard grace period, which can be stated up front in future retirement bugs of this nature.

Congratulations @carlwgeorge. Use your new powers wisely ;) (You might need to log out and then back in at src.fp.o to be able to.)

Metadata Update from @churchyard:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

Metadata