di
commented
1 year ago Thanks for the issue. This is indeed a shortcoming in our implementation, mostly due to the fact that a 'Maintainer' had no access to the 'manage' view which allows an 'Owner' to act on a project or release, including yanking, so this would have required a bit of an overhaul of the UI.
That said, I think the actual issue is what you sort of alluded to, that the delineation of abilities between the 'Owner' and 'Maintainer' roles and their naming doesn't really map to what people actually want, which I think is:
- a 'non-destructive' role that can do things like publish and yank
- a more powerful 'administrator' role that can do things like add collaborators and delete files/releases
jvanasco
What's the problem this feature will solve?
PEP529 described the functionality for "authors" to "yank" a release.
#5837 is the corresponding Warehouse ticket for the initial implementation of enabling a "maintainer" to "yank" a release.
While the PEP notes "authors" and the ticket (and numerous announcements) notes "maintainers", this functionality is actually limited to only "Owners" (as defined within Warehouse/PyPi).
As project contributors/maintainers know, Warehouse utilizes two roles in project management - "Owners" and "Maintainers". "Maintainers" only have the ability to upload releases; while "Owners" have an extended permission set including the abilities to (i) manage project settings, (ii) add maintainers, and (iii) delete (or yank) releases.
It is typical for older or larger projects to have an "Owner" who is no longer actively involved, and one or more "Maintainers" who handle the day-to-day operations and release management. This distribution of responsibilities often occurs in "critical" PyPi projects Extensive problems can occur to CI Systems and downstream consumers when a "Maintainer" accidentally uploads a release with incorrect metadata and is unable to unpublish it. It can take weeks or months (if ever) to activate the project "Owner" to yank the release. When a release contains bad metadata, package installers such as
pipmay believe the release is usable in an incompatible environment; a new patch release will not fix this problem, as package installers will continue to see the incompatible release until it is yanked."Version pinning" is not a viable alternative, as CI systems for FOSS software often need to test unpinned to ensure compatibility; and this can require tens/hundreds/thousands of developers to temporarily pin the release, with a note to unpin once the issue is fixed upstream.
Describe the solution you'd like
Project "Maintainers" should be able to "yank" a release - which upholds the apparent spirit and intent of the PEP, ticket, and the expectations set by reading various announcements. Yanking a release is a reversible action and no files are deleted.
This should not pose any security issues or other concerns itself, but the ability could be restricted to only allow the maintainer who uploaded a release to "yank" it; "Owners" would still be able to "yank".
Additional context
I hate to sound pedantic, but I implore PyPi/Warehouse contributors and Staff to please be careful when using the term "Maintainer" in relation to these projects/services because "Maintainer" is a specifically defined role and permission set, and "Maintainer" is often used instead of "Owner" across tickets and announcements.