Hi,
I'm working on a tool to make it easier to create EPEL branch requests in the case where there are transitive dependencies that also need to be branched.
I'm basing it on https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL which provides some guidelines and some templates; however, it is a bit vague on some aspects, namely:
which product and component should the bug be filed against?
I've been using Fedora/rawhide (with the FutureFeature keyword) if the package has never been branched for EPEL before, and 'Fedora EPEL' / epelX (where X is the branch requested) if it has, however, I can't find a written document where this is recommended, though I thought I've read it somewhere in the past.
If I can simply use Fedora/rawhide, this would simplify the tool a lot: - we can almost always assume there is a {'product: 'Fedora', 'component': srpm} with some rare exceptions e.g. the srpm is in base CentOS but has missing subpackages (see recent discussion on the topic) - if the package is branched for EPEL at some point, we can file the request against {'product': 'Fedora EPEL', 'component': srpm}. But what version to file against? - bpython: https://bugzilla.redhat.com/show_bug.cgi?id=1782782 phoronix-test-suite: https://bugzilla.redhat.com/show_bug.cgi?id=1976280 these are the ideal cases; the request is for an 'epel8' branch and 'epel7' and 'epel8' are listed as available versions, so the request was filed against 'epel8' - nextcloud-client: https://bugzilla.redhat.com/show_bug.cgi?id=1972910 this is a request for 'epel8-next', but that is not available as a product
The tool will thus need to query Bugzilla to locate the component on either Fedora EPEL or Fedora, and then figure out what versions are listed; from my initial experimentation with python-bugzilla: https://github.com/python-bugzilla/python-bugzilla this does not seem trivial.
If filing against Fedora/rawhide is fine, I can edit the wiki to match. It should probably also mention that the EPEL Packagers SIG group can be added as a co-maintainer, but I'll experiment with the wording first when testing the tool.
Thanks,
V Wed, Jul 07, 2021 at 06:33:51PM -0700, Michel Alexandre Salim napsal(a):
I'm working on a tool to make it easier to create EPEL branch requests in the case where there are transitive dependencies that also need to be branched.
I'm basing it on https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL which provides some guidelines and some templates; however, it is a bit vague on some aspects, namely:
which product and component should the bug be filed against?
I've been using Fedora/rawhide (with the FutureFeature keyword) if the package has never been branched for EPEL before, and 'Fedora EPEL' / epelX (where X is the branch requested) if it has, however, I can't find a written document where this is recommended, though I thought I've read it somewhere in the past.
If I can simply use Fedora/rawhide, this would simplify the tool a lot:
- we can almost always assume there is a {'product: 'Fedora', 'component': srpm} with some rare exceptions e.g. the srpm is in base CentOS but has missing subpackages (see recent discussion on the topic)
- if the package is branched for EPEL at some point, we can file the request against {'product': 'Fedora EPEL', 'component': srpm}. But what version to file against?
- bpython: https://bugzilla.redhat.com/show_bug.cgi?id=1782782 phoronix-test-suite: https://bugzilla.redhat.com/show_bug.cgi?id=1976280 these are the ideal cases; the request is for an 'epel8' branch and 'epel7' and 'epel8' are listed as available versions, so the request was filed against 'epel8'
- nextcloud-client: https://bugzilla.redhat.com/show_bug.cgi?id=1972910 this is a request for 'epel8-next', but that is not available as a product
The tool will thus need to query Bugzilla to locate the component on either Fedora EPEL or Fedora, and then figure out what versions are listed; from my initial experimentation with python-bugzilla: https://github.com/python-bugzilla/python-bugzilla this does not seem trivial.
If filing against Fedora/rawhide is fine, I can edit the wiki to match. It should probably also mention that the EPEL Packagers SIG group can be added as a co-maintainer, but I'll experiment with the wording first when testing the tool.
The algorithm for filing bugs is complicated because there are Fedora maintainers who do not want to deal with EPEL. If I were one of them I would feel offended that I'm getting requests for EPEL 8 if there is already EPEL 7 maintainer.
I want to say you should bite the bullet and implement it in the complicated way.
-- Petr
On Thu, Jul 8, 2021 at 1:20 AM Petr Pisar ppisar@redhat.com wrote:
V Wed, Jul 07, 2021 at 06:33:51PM -0700, Michel Alexandre Salim napsal(a):
I'm working on a tool to make it easier to create EPEL branch requests in the case where there are transitive dependencies that also need to be branched.
I'm basing it on
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL
which provides some guidelines and some templates; however, it is a bit vague on some aspects, namely:
which product and component should the bug be filed against?
I've been using Fedora/rawhide (with the FutureFeature keyword) if the
package
has never been branched for EPEL before, and 'Fedora EPEL' / epelX
(where X is
the branch requested) if it has, however, I can't find a written
document where
this is recommended, though I thought I've read it somewhere in the past.
If I can simply use Fedora/rawhide, this would simplify the tool a lot:
- we can almost always assume there is a {'product: 'Fedora',
'component': srpm}
with some rare exceptions e.g. the srpm is in base CentOS but has
missing
subpackages (see recent discussion on the topic)
- if the package is branched for EPEL at some point, we can file the
request
against {'product': 'Fedora EPEL', 'component': srpm}. But what
version to file
against?
- bpython: https://bugzilla.redhat.com/show_bug.cgi?id=1782782 phoronix-test-suite:
https://bugzilla.redhat.com/show_bug.cgi?id=1976280
these are the ideal cases; the request is for an 'epel8' branch and
'epel7' and
'epel8' are listed as available versions, so the request was filed
against 'epel8'
- nextcloud-client:
https://bugzilla.redhat.com/show_bug.cgi?id=1972910
this is a request for 'epel8-next', but that is not available as a
product
The tool will thus need to query Bugzilla to locate the component on
either
Fedora EPEL or Fedora, and then figure out what versions are listed;
from my
initial experimentation with python-bugzilla:
https://github.com/python-bugzilla/python-bugzilla
this does not seem trivial.
If filing against Fedora/rawhide is fine, I can edit the wiki to match.
It should
probably also mention that the EPEL Packagers SIG group can be added as
a co-maintainer,
but I'll experiment with the wording first when testing the tool.
The algorithm for filing bugs is complicated because there are Fedora maintainers who do not want to deal with EPEL. If I were one of them I would feel offended that I'm getting requests for EPEL 8 if there is already EPEL 7 maintainer.
I want to say you should bite the bullet and implement it in the complicated way.
-- Petr
I second what Petr said. Do the check to see if it's in 'Fedora EPEL' and proceed appropriately. I think it would also be good to change the wording a bit depending on if it's already in EPEL or not.
Troy
On Thu, Jul 08, 2021 at 06:24:57AM -0700, Troy Dawson wrote:
On Thu, Jul 8, 2021 at 1:20 AM Petr Pisar ppisar@redhat.com wrote:
V Wed, Jul 07, 2021 at 06:33:51PM -0700, Michel Alexandre Salim napsal(a):
I'm working on a tool to make it easier to create EPEL branch requests in the case where there are transitive dependencies that also need to be branched.
I'm basing it on
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL
which provides some guidelines and some templates; however, it is a bit vague on some aspects, namely:
which product and component should the bug be filed against?
I've been using Fedora/rawhide (with the FutureFeature keyword) if the
package
has never been branched for EPEL before, and 'Fedora EPEL' / epelX
(where X is
the branch requested) if it has, however, I can't find a written
document where
this is recommended, though I thought I've read it somewhere in the past.
If I can simply use Fedora/rawhide, this would simplify the tool a lot:
- we can almost always assume there is a {'product: 'Fedora',
'component': srpm}
with some rare exceptions e.g. the srpm is in base CentOS but has
missing
subpackages (see recent discussion on the topic)
- if the package is branched for EPEL at some point, we can file the
request
against {'product': 'Fedora EPEL', 'component': srpm}. But what
version to file
against?
- bpython: https://bugzilla.redhat.com/show_bug.cgi?id=1782782 phoronix-test-suite:
https://bugzilla.redhat.com/show_bug.cgi?id=1976280
these are the ideal cases; the request is for an 'epel8' branch and
'epel7' and
'epel8' are listed as available versions, so the request was filed
against 'epel8'
- nextcloud-client:
https://bugzilla.redhat.com/show_bug.cgi?id=1972910
this is a request for 'epel8-next', but that is not available as a
product
The tool will thus need to query Bugzilla to locate the component on
either
Fedora EPEL or Fedora, and then figure out what versions are listed;
from my
initial experimentation with python-bugzilla:
https://github.com/python-bugzilla/python-bugzilla
this does not seem trivial.
If filing against Fedora/rawhide is fine, I can edit the wiki to match.
It should
probably also mention that the EPEL Packagers SIG group can be added as
a co-maintainer,
but I'll experiment with the wording first when testing the tool.
The algorithm for filing bugs is complicated because there are Fedora maintainers who do not want to deal with EPEL. If I were one of them I would feel offended that I'm getting requests for EPEL 8 if there is already EPEL 7 maintainer.
I want to say you should bite the bullet and implement it in the complicated way.
-- Petr
I second what Petr said. Do the check to see if it's in 'Fedora EPEL' and proceed appropriately. I think it would also be good to change the wording a bit depending on if it's already in EPEL or not.
Troy
Thanks both (and Carl, who replied on IRC). I was also surprised to not find the algorithm documented, at least not in that document, so I'll add that.
I might eventually extend python-bugzilla a bit to make it easier to do this. A lot of the operations seem to assume it's a small Bugzilla instance an would try to pre-load all the components for a given product.
Best regards,
On Thu, Jul 8, 2021 at 11:08 AM Michel Alexandre Salim michel@michel-slm.name wrote:
I might eventually extend python-bugzilla a bit to make it easier to do this. A lot of the operations seem to assume it's a small Bugzilla instance an would try to pre-load all the components for a given product.
Your comment about pre-loading too much reminded me of https://github.com/python-bugzilla/python-bugzilla/issues/49 . I think some of those things might be historical accidents from earlier Bugzilla APIs that did not give all the information we needed.
- Ken
On Thu, Jul 08, 2021 at 12:14:09PM -0400, Ken Dreyer wrote:
On Thu, Jul 8, 2021 at 11:08 AM Michel Alexandre Salim michel@michel-slm.name wrote:
I might eventually extend python-bugzilla a bit to make it easier to do this. A lot of the operations seem to assume it's a small Bugzilla instance an would try to pre-load all the components for a given product.
Your comment about pre-loading too much reminded me of https://github.com/python-bugzilla/python-bugzilla/issues/49 . I think some of those things might be historical accidents from earlier Bugzilla APIs that did not give all the information we needed.
Thanks for that pointer! I'll probably end up using the Pagure API as much as possible, and using `python-bugzilla` as little as possible, until I have time to look at it.
Best,
epel-devel@lists.fedoraproject.org