Dne 19. 12. 24 v 9:55 Daniel P. Berrangé napsal(a):
On Thu, Dec 19, 2024 at 09:26:37AM +0100, Vitaly Zaitsev via devel wrote:On 18/12/2024 22:59, Simon de Vlieger wrote:What I'd like to see is to remove provenpackagers, do everything through PRs and have a separate SIG/group that can fast-track and merge any PR.Not an option because when we update some important libraries, we need to rebuild more than 50 packages. If we have to use pull requests and wait for them to be merged, it will take forever to push updated versions of these libraries.For these situations IMHO it would be better if we did not need to have provenpackagers trigger the rebuilds. We should have a fully automatable way for *any* package to trigger a rebuild of dependent things. If the person does not need to make any changes to the spec, directly, only through an automated tool, there would be no need for the elevated provenpackagers privilege and it would also avoid any risk of complaints of unrelated changes being made at the same time. In the context of such rebuilds, provenpackagers is simply a workaround for our insufficient automation.
I would be more then happy if there was some automation helping with e.g. mass rebuild of Ruby, which is my main use case for having PP. But I don't think it is realistic to expect anything like this any time soon 😔
There are also packages such as e.g. rubygem-json, which are maintained by PP, despite having their (unresponsive?) maintainer. Granted, this is unfortunate situation. But apparently, it does not bother anybody that much. I'd rather use my PP privileges (and I'd not have anything against using PR in cases like this) then go through unresponsive maintainer process (maybe just to learn that they are actually responsive solely for unresponsive process 🤷. And just FTR, it took me years to officially overtake the "ruby" package).
Vít
With regards, Daniel
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
