Sponsors, please vote in this ticket. (I've sent out the announcement to sponsors.)

@oliver Could you please elaborate on why do you believe you need to be a provenpackager in order to help here and there in a meaningful way?

I'd like to know why you need to be a provenpackager to help. Especially in EPEL branches.

From his introduction, it sounded like he wants to avoid needing to request comaintainership on a lot of individual packages in order to branch and build them for EPEL. That seems like a reasonable justification for having the privileges to me.

I don't have any first-hand knowledge of @oliver's packaging efforts, so I'll abstain from voting either way.

From his introduction, it sounded like he wants to avoid needing to request comaintainership on a lot of individual packages in order to branch and build them for EPEL. That seems like a reasonable justification for having the privileges to me.

It actually seems like a means of run and dump to me TBH, people branching/building without agreement of the maintainers and without co-maintaining the epel8 branch isn't a means of getting quality well maintained packages in EPEL-8 where I would have thought we want longevity.

From his introduction, it sounded like he wants to avoid needing to request comaintainership on a lot of individual packages in order to branch and build them for EPEL. That seems like a reasonable justification for having the privileges to me.

I respectfully disagree. This is not how things are supposed to be done. There even was a quite recent discussion of provenpackagers doing this and the consensus seemed to be that this is not OK. (I can dig for links, but @ngompa might remember that.)

Good morning guys.
I shouldn't write such requests on the run. I understand there wasn't enough context for you guys - sorry for that. I completely understand the cautiousness with this request.

A bit more background about me:
Fedora community member since the very early days. I used to be secondary arch maintainer (Alpha) until we gave up on this project - ha, the group still exists in FAS :-)
I'm currently a TAM at Red Hat and for me, doing some packaging stuff will make sure I don't lose the those skills, that I always enjoyed :-)

So, the story is the following. A lot of my customers complaint that packages that are in EPEL 7 are not available in EPEL 8 and some BZs are lingering around and nobody touches them.
On the other hand, I see and hear from some packagers that they didn't have the time yet to get some RHEL/CentOS 8 system in shape to be able to support the packaging efforts.
Yes, mock helps a bit, but as soon as it comes applications that require a GUI/running X, without a VM, that's a bit of a pain.

For sure, provenpackager doesn't mean communication can be skipped! That's not my intend. But it would reduce the hassle of explaining each and every single package maintainer how to give me the right permissions; I can reach out to the ppl <package>-maintainers@fedoraproject.org and ask them for a simple, informal 'OK', which they can easily give on the run from their mobile phone.
Some packagers are maintaining packages since a long time - back from the days when we still had PackageDB and it was pretty simple to request and approve co-maintainership; Some don't know the new process... So, in some cases, it's more effort to explain the "new" stuff.

TL;DR. I want to help to bring EPEL 8 in better shape. This will help my/our customers in adopting RHEL 8 and I'm offering a helping hand to those packagers who struggle in some way with EPEL 8 - for whatever reason.

Thanks guys,
Oliver

I disagree. If you use proven-packager rights to maintain packages in EPEL8 branch, then we literally lose the information who maintain that package/branch.

If you want to get EPEL8 into better shape, I suggest you actually ask for co-maintainership (either commit or admin access) of the packages you want to provide for EPEL8. If you don't do that, they'll probably just bitrot after your initial contribution, since there'll be no way to associate you or notify you of problems with those packages after the fact.

Additionally, with the next version of pagure (5.9.1, already deployed in staging), it will be possible to override EPEL POCs simply from the pagure web UI, which should make it clear who's responsible for what, and I think that's the best solution for this "problem".

Now, I understand that it might be "simpler" to just request epel8 branches for the packages you want, push your changes, and leave - but that only puts the burden of actually looking after the package in the epel8 branch on the original maintainer - without them even being involved in the process.

This happened to me not long ago - somebody created an epel8 branch for one of my packages and built the package there, without me being involved at all (it was also done before I even had time to intervene). I don't care or have time to maintain this package additionally for EPEL8, so it now just sits there without getting any attention (or security updates, for that matter).

Another matter would be if you had to deal with non-responsive maintainers a lot. In that case, provenpackager powers actually not only make your work easier, but they make it possible. But you have not mentioned that, so I assume you've not had to deal with non-responsive maintainers yet.

-1.

Another matter would be if you had to deal with non-responsive maintainers a lot. In that case, provenpackager powers actually not only make your work easier, but they make it possible. But you have not mentioned that, so I assume you've not had to deal with non-responsive maintainers yet.

Using provenpackager power to deal with non-responsive maintainers is OK to fix problems. It is still not OK to introduce packages like this to EPEL, because it makes the problem worse: Now the non-responsive maintainer has an extra thing to be non-responsive about.

Anyway, -1 here as well.

Ack.
I got your very valid points - obviously I didn't think this through completely.
I'll therefore request co-maintainership on the packages in question and if I encounter too many non-responsive maintainers, you'll get a new ticket :-P

Thanks guys for the fruitful discussion and the insights!

As a side note, I've opened this: https://pagure.io/epel/issue/101

Reopened by accident.