On 01. 09. 22 0:19, Troy Dawson wrote:
A - At the very least, we need to change the wording of the bugs. I am
proposing the following
Subject: Remove <package> from epel9 when rhel 9.1 is released
Comment: This package is being added to RHEL 9.1 at the next minor release.
After the next RHEL minor release, please verify this package was released in
RHEL, and if so remove it from epel9.
Yes please. Ideally, even add a reproducer that verifies this ("go to X and
search for the package name" or "run this repoquery" or even "go to
documentation page to check it")
B - If possible, move the EPEL2RHEL check to later in the development
would like it to be in the step where the packages get added to BaseOS,
AppStream, or CRB. That way we would know it isn't going to be a BuildRoot
only package, and it would reduce the time the bugs sit waiting.
I don't know if this is possible, but I'm going to ask.
Agreed. It could even say which (sub)packages are being added and link to the
appropriate documentation in case some of the EPEL subpackages need to be split
into a spearate component.
C - ?? What if we only created the bugs on the tracker itself, and
individual packages ??
Would that be a good thing? Or would it irritate the maintainers?
What do you mean by this? I don't understand it. File it against the
distribution? If there is a dedicated (and educated) person/team who would deal
with this at all RHEL release boundaries, than this makes sense. Otherwise it
just hides this information from the EPEL maintainers.