PEP 541 says maintainers should attempt to contact a package owner at least three times and stop trying after six weeks when evaluating an abandoned or unreachable project. I assumed that meant a package-name transfer would usually be resolved within roughly that timeframe, but many requests seem to take around six months, with little visible progress after the first week or two.
For projects that have gone 10–14 years without updates, have no usable source repository, were apparently created for name-squatting, or have owners who never respond, the process feels especially slow. Is the six-week period only part of the process rather than a target for the complete review? Is the delay mainly caused by the backlog and limited staffing, or are there additional security checks that make these cases difficult?
5 Answers
The six-week period mainly describes the contact attempts, not necessarily the total time until a transfer is approved. There can also be waiting periods between attempts, evidence review, and a final decision by a small number of people with the authority to transfer a name. Most volunteers can triage cases, but the final approval is a bottleneck.
This is difficult to automate safely. A dormant package may have a maintainer email on an expired domain, and someone else could register that domain and appear to be the owner. Since package transfers can affect a large number of users, a human has to evaluate whether the evidence is trustworthy. The security risk is one reason the bar is intentionally high.
A renewal or keep-alive system could reduce the need to interpret silence: maintainers of important packages would periodically confirm that they still control the project. However, automatic expiration has its own risks, since a legitimate maintainer could forget to renew and lose a widely used name. More funding and engineering support would probably help more than simply shortening the review rules.
The service is handling an enormous package index with a largely manual process and very limited staffing. Abandonment cases compete with lost-login requests, policy exceptions, security work, and normal infrastructure maintenance. The backlog makes six months a fairly normal wait, even when an individual case seems straightforward.
If a package is genuinely abandoned, using a new name is usually the safest option. Reassigning an old name can break existing dependency files or let a malicious project receive unexpected installs. A possible improvement would be better support for marking abandoned projects and registering replacement packages, rather than automatically transferring ownership.
That makes sense. My concern is less that every transfer should be automatic and more that the published timeline creates an expectation that cases will keep moving after the contact period ends. Updating the guidance or showing clearer status information would probably reduce a lot of frustration.