On Fri, Jan 10, 2025 at 11:33:35AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jan 06, 2025 at 01:18:35PM -0500, Stephen Smoogen wrote: > > On Mon, 6 Jan 2025 at 12:50, Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > > > > > 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.' > > The page says "They [pps] 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." So… I'd say that this actually is fairly clearly > specified. "needlessly" and "minimal" are doing a lot of heavy lifting there and very much open to interpretation. If there's a reason why we want a rebase of libnova & the maintainer is not handling it (and crucially has not explicitly rejected it), then 'needlessly' arguably wouldn't apply. Thus doing a rebase with no/few other changes to the package could be considered the "minimal" fix for the problem of not having the newer version. Yes, applying a non-responsive maintainer process may well be applicable as a desirable course of action, but I don't think that automatically means a PP shouldn't do a rebase if beneficial in the meantime/parallel. > > 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. > > Actually, I'm not sure if this has changed that much. We have this: > > To exclude a package from provenpackagers access, you have to open a > > ticket at FESCo issue tracker and explain why provenpackagers should > > not have access to it. > This text is ancient and AFAIK, no such ticket has ever been filed. > But this shows that people were worried about pps doing too much > even a decade+ ago. If no such ticket was ever filed, I'd suggest it shows that the original fear was overstated / not realized to a great extent. IOW despite periodic disagreements, the community is usually OK with what PP have been doing in practice. I might actually go as far to say *occassional* disagreements over PP actions are actually a healthy thing. If we never had any disagreements, then it would be a sign that PPs are too timid / afraid / locked down in making changes, and thus we are loosing the potential benefits the concept of PPs brings. If we had regular disagreements, then it would be a sign that PPs are too bold in their changes, overstepping what's expected. Occassional disagreements are a sweet spot where PPs are being bold enough to solve important problems, and only rarely making mistakes. > A free-for-all for pps was never the norm. Strictly controlling/designating the precise actions of pps was also not the norm, in practice, despite what may be written in guidelines. The leeway to make reasonable judgement calls on a case by case basis has effectively been/become the norm for quite a long time AFAICS. Even if some judgement calls may be incorrect in hindsight, it is the big picture that matters. If the project gains more from the things that PP do well, than we loose from the occassional mis-judgement, that is good. No matter what guidelines say, there will always be mistakes as we are all human. We should be wary of trying to make things too strict as we'll risk loosing too many benefits, compared to problems we might eliminate. Most of our disagreements seem to revolve around prior communication of intended actions, rather than the substance of those actions. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ 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
