On Fri, Sep 19, 2014 at 9:26 PM, Richard Jones <richard@python.org> wrote:
When someone requests to take over a listing on PyPI, the process is: i * If the request comes in through some means other than the sf.net support tracker, I require the requestor to make the request through that tracker so there is a record,ard * I ask whether they have contact the current owner, * I personally contact the owner through whatever means I have (sometimes this means using the address listed for the user in PyPI, sometimes that address is not valid so I use other means where possible),
This seems like the step where change would be most fruitful. The idea of a public list mentioned before allows a variety of feedback: 1) The maintainer themselves 2) People who know the maintainer and have an alternate method to contact them 3) Other people who know the project and can raise an objection to the exact person who is being added as a new owner Another thought here is that it's often best to use every means of contacting someone that you reasonably have available. So if there's a valid mail in pypi and a valid email in your contacts, use both. The public list idea essentially lets you crowdsource additional methods of contacting the maintainer.
There's been some suggestions made:
* Publicly announcing the intention to make the change is a good one, though again finding an appropriate forum that enough people would actually read is tricky.
If there's no appropriate forum, starting a new one might be the best. "Uploaders to pypi" could certainly be seen as an audience that doesn't match well with any other existing mailing list.
In light of this specific case, I have an additional change that I think I'll implement to attempt to prevent it again: In the instances where the current owner is unresponsive to my attempts to contact them, *and* the project has releases in the index, I will not transfer ownership. In the cases where no releases have been made I will continue to transfer ownership.
This is tricky. There are certainly security issues with allowing just anyone to take over a popular package at any time. But there are also security concerns with letting a package bitrot on pypi. Say that the 4 pypi maintainers of Django or the 6 pypi maintainers of pip became unresponsive (it doesn't even have to be forever... that 6 month sabbatical could correspond with something happening to your co-maintainers as well). And the still active upstream project makes a new security fix that they need to get into the hands of their users ASAP. We don't want pypi to block that update from going out. Even if the project creates a new pypi package name and uploads there, would we really want the last package on pypi that all sorts of old documentation and blog posts on the internet is pointing to to be the insecure one? So I don't think an absolute "we will never transfer ownership once code is released" is a good idea here. It's a good idea to increase the means used to determine if the current maintainer can be reached and it's a good idea to throw extra eyes at vetting whether a transfer is warranted. It may be a good idea to add more criteria around what makes for an allowable transfer (for instance, in my examples, there's still a large, well known canonical upstream even though the specific members of that upstream responsible for uploading to pypi have gone unresponsive. That might be a valid criteria whereas one-coder projects being replaced by other one-coder forks might be a case where you simply say "rename please"). It could help to have other people involved in the decision making for this. At the least, having other people involved will spread responsibility. At best it gives the group additional man-hours to research the facts in the case. One final thought in regards to ticket 407. My impression from reading the notes is that this was not a complete invalidation of the current process. In the end, the current owner was alerted to the takeover attempt and also was in a position to do something about it since they disagreed with what was happening. Those are both points in favor of some pieces of the process (adding the new owner instead of replacing the owner). This might not be sufficient for a malicious attack on a project but it does show that the process does have some good features in terms of dealing with mistakes in communication. -Toshio