In my experience through the years, I've found very little proven packagers that would work in what *I would see* as the right way. I too despise random interventions from the higher power to my packages. I rejoiced when the new process of removing inactive proven packagers took place. And I'd love to see the proven packagers losing their rights regularly for breaking the guidelines. (Especially when there's nothing much stopping them to request the proven packager status again and again, but I hope in the small PITA of doing that might give them time for a reflection on why they lost it and try better next time) "Prior to making changes, provenpackagers should try to communicate with owners of a package in bugzilla, dist-git pull request, IRC, matrix, or email. They should be careful not to change other people’s packages needlessly and try to do the minimal changes required to fix problems, as explained more in depth in Who is Allowed to Modify Which Packages." https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ In this particular case, if the commit was urgently needed by the proven packager, I'd expect at least an explanation in the commit message, what bigger whole this is part of (link to BZs or Fedora change, or something). If it wasn't urgent, I'd say PR would be in place instead. (with the same reasoning included in the commit message) I was raised (as a maintainer) watching closely the proven packager 'praiskup', which uses his powers conscientiously like no other proven packager I've ever experienced. Especially early in my packager career, I've gone to him many times, asking for proven packager intervention that would come handy to me. I was refused every time, with a good explanation of the processes I should take before residing to the very last option - the proven packager intervention. It taught me a lot. Through the years I was even thinking about becoming a proven packager myself several times. However I haven't requested it in the end, because, even when I did changes across dozens and dozen of packages, there was never ever a time, where I would *need* to reside to the proven packager powers to get my work done, as the standard ways of contacting regular owners of the packages before that always worked. (PR then BZ, then mail, then mailing list. I haven't even needed to activate 'Policy for nonresponsive package maintainers'.) But I have a strong feeling the proven packagers powers are commonly used because they are handy, instead of them being necessary. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Dec 1, 2023 at 11:35 PM Mamoru TASAKA <mtasaka@xxxxxxxxxxxxxxxxx> wrote: > > Sérgio Basto wrote on 2023/12/02 0:49: > > On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote: > >> So, due to me following my package (notmuch) upstream and testing > >> early against upstream's git, reporting and working with upstream, I > >> noticed a FTBFS and helped fixing it. Nothing urgent since it was > >> basically just a test failing for the wrong reasons. > >> > >> Within a few days, upstream releases a patch release. Within hours, > >> I'm testing (again, since it's basically what was on git already) on > >> copr and koji, writing a nice commit message, push to rawhide ... > >> > >> ... and get a reject because someone thought that pushing directly > >> without asking or at least notifying the maintainer would be in > >> order: > >> > >> https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffdb1fdc35c7b31?branch=rawhide > > > > > >> Why? For a FTBFS due to a test? No bugzilla, no FTI, no security > >> issue whatsoever? > >> > > > > You may kindly ask to mtasaka why did it ? , and also alert him that > > package is well maintain and have a quick response and kindly ask to do > > PR instead , he is one provenpackager and I sure that he did that in > > hope of improve the package, I'm sure that he will understand. > > > > Best regards, > > So to explain, notmuch was FTBFS. > And we are going to rebuild packages which depends on libruby.so.3.2 as > announced as: > > https://fedoraproject.org/wiki/Changes/Ruby_3.3 > > We are testing beforehand whether packages can rebuild against new ruby > beforehand, and trying to fix **just** FTBFS beforehand because if the package > has FTBFS anyway (regardless of whether the reason is related to ruby or > not, such package will have broken deps after mass rebuild). > > notmuch is this target. > > Regards, > Mamoru > > > > > > > > >> I am sick of this. Really. I am so sick of this way of stomping on > >> each others' feet. > >> > >> It's made worse by failing automated notifications, of course. Not > >> from pagure about the push nor from koji about the build nor from > >> bodhi about the update. > >> > >> Dunno whether it's the new fmn or what. That works for *my* actions > >> with pagure/bodhi/koji but fails to report copr actions to me, and > >> apparently also actions by others. > >> > >> Thanks for listening ... > >> > >> Michael > >> -- > -- > _______________________________________________ > 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 -- _______________________________________________ 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
