#10866 Stalled EPEL Requests don't follow the policy
Closed: Fixed a month ago by churchyard. Opened 9 months ago by churchyard.

  • Describe the issue

I've observed several Stalled EPEL Requests here in this tracker. At least for the few recent once I've checked, the policy was not completely followed.

The policy is https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests

The part that is not followed is:

the packager is made the Bugzilla contact for EPEL

I believe this is a very essential part of the policy. If we are not following that, the packages will exist in EPEL but the Fedora maintains (or the previous EPEL maintainers) who clearly were not interested in maintaining the package in EPEL will remain the Bugzilla contact for EPEL.

Please, walk over the "fixed" Stalled EPEL Requests and make the packagers who opened it the Bugzilla contact for EPEL. When handling new Stalled EPEL Requests, make sure the person is not only added as a collaborator for epel branches, but also the Bugzilla contact for EPEL.

Thanks.

  • When do you need this?

I'd like the next Stalled EPEL Requests to follow the policy. Other than that, going through the list of previous requests can happen later.

  • When is this no longer needed or useful? When the policy changes.

  • If we cannot complete your request, what is the impact?

Not interested or non-responsive maintainers will wrongly be the Bugzilla contact for EPEL.


Hi @churchyard, can you point me to such requests? I checked some random from the closed queue and I can see the default assignee in bz set correctly.

There is one situation when I do not set the epel component BZ contact and that is when its new package addition to epel. In this case, there is no epel component to set to contact on.

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

9 months ago

can you point me to such requests?

https://pagure.io/releng/issue/10846
https://pagure.io/releng/issue/10843
https://pagure.io/releng/issue/10835
https://pagure.io/releng/issue/10834
https://pagure.io/releng/issue/10833
https://pagure.io/releng/issue/10831
https://pagure.io/releng/issue/10830
https://pagure.io/releng/issue/10818
https://pagure.io/releng/issue/10814
https://pagure.io/releng/issue/10813
https://pagure.io/releng/issue/10806
...

Those are the first results of https://pagure.io/releng/issues?status=Open&search_pattern=Stalled+EPEL&close_status=Fixed -- I suspect the lists goes on.

There is one situation when I do not set the epel component BZ contact and that is when its new package addition to epel. In this case, there is no epel component to set to contact on.

I do not understand what you mean. The EPEL Bugzilla point of contact can be set to any component at https://src.fedoraproject.org/rpms/

I do not understand what you mean. The EPEL Bugzilla point of contact can be set to any component at https://src.fedoraproject.org/rpms/

The edit button changes it in the pagure but not in bugzilla.

I am setting the default BZ assignee here:
https://bugzilla.redhat.com/editcomponents.cgi?action=edit&product=Fedora%20EPEL&component=<package-name>

There is a toddler that syncs from pagure-> bugzilla. You should not need to do this manually.

If that toddler is broken/not working we should fix it.

The edit button changes it in the pagure...

That is exactly what I am asking here for, thanks.

Metadata Update from @amedvede:
- Issue assigned to amedvede

8 months ago

pagure-dist-git has a https://src.fedoraproject.org/_dg/bzoverrides/rpms/PKGNAME api endpoint that can be used to automate this.

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

a month ago

Login to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog