Where should branch requests be filed?

[Michel Alexandre Salim]

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,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/[e-mail]

[Petr Pisar]

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

[Troy Dawson]

On Thu, Jul 8, 2021 at 1:20 AM Petr Pisar <ppisar(a)redhat.com&gt; 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

[Michel Alexandre Salim]

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(a)redhat.com&gt;
> 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,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/[e-mail]

[Ken Dreyer]

On Thu, Jul 8, 2021 at 11:08 AM Michel Alexandre Salim
<michel(a)michel-slm.name&gt; 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

[Michel Alexandre Salim]

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(a)michel-slm.name&gt; 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,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/[e-mail]