On Mon, 6 Jan 2025 at 12:50, Fabio Valentini <decatho...@gmail.com> wrote:
> On Mon, Jan 6, 2025 at 6:03 PM Stephen Smoogen <ssmoo...@redhat.com> > wrote: > > > > On Mon, 6 Jan 2025 at 11:49, Fabio Valentini <decatho...@gmail.com> > wrote: > >> > >> On Mon, Jan 6, 2025 at 10:05 AM Mattia Verga via devel > >> <devel@lists.fedoraproject.org> wrote: > >> > > >> > Despite 0.16 being available as tag in repository since 2015, libnova > >> > was never updated and it's still 0.15 in Fedora. > >> > > >> > I have notified the package maintainer long ago [1], but I never got a > >> > reply. So I plan to push an update as provenpackager, which will > include > >> > a soname bump (from libnova-0.15.so.0 to libnova-0.16.so.0) and > rebuild > >> > all dependent packages in a side-tag for Rawhide. The list of affected > >> > packages is: > >> > >> Please don't use provenpackager privileges for this kind of thing. > >> If the maintainer is truly unresponsive, that's what the unresponsive > >> maintainer process is for. > > > > > > If this is not what 'proven packagers' are allowed to do, it might be > good to have everyone who has proven packager go through some sort of > "retraining" as what Mattia announced doing has been common practice for a > long time. It actually seems covered by > https://docs.fedoraproject.org/en-US/fesco/Who_is_allowed_to_modify_which_packages/ > > > > If the packager doesn’t keep track of those items, then other > experienced packagers are free to fix stuff for them. > > > > I am expecting that this is an area which needs more clarity. > > On the page you linked, there's a list of examples of situations when > using PP privileges is appropriate, just below the paragraph you > quoted - security issues, bugs that cause data loss, etc. But "just > update to a new version" is not on the list. That's clear enough in my > It may be 'clear' to you but I don't see it listed as 'This is the limited list of actions that a proven packager may take. Anything outside of that should not be done.' We have given proven packagers a lot of leeway to use their best judgement to make the distribution better for a very long time. I can understand that stronger limits are expected now, but it should be made much clearer. > book ... but sure, documentation can always be improved. For example, > I'm not sure if this page predates the non-responsive maintainer > process (it feels very old), so maybe it just has never been adapted > to its existence. > > Fabio > -- > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
