<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 September 2014 04:47, Daniel Greenfeld <span dir="ltr"><<a href="mailto:pydanny@gmail.com" target="_blank">pydanny@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In order to claim a package as being abandoned it should undergo a<br>
formal process that includes:<br>
<br>
* Placement on a PUBLIC list of packages under review for a grace<br>
period to be determined by this discussion<br></blockquote><div><br></div><div>This is not done at present. Can you suggest a public forum that would reach a useful audience?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Formal attempts via email and social media (twitter, github, et al)<br>
to contact the maintainer.<br></blockquote><div><br></div><div>This is done at present, using the contact details registered with pypi. Or other contact methods if that fails.</div><div><br></div><div>I always default to asking the current maintainer of a package to transfer it to a new maintainer.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Investigation of the claimant for the rights to the package. The<br>
parties attempting to claim a package may not be the best<br>
representatives of the community behind that package, or the Python<br>
community in general.<br></blockquote><div><br></div><div>I'm not sure how I could do this reasonably given the breadth of packages in the index, and the size and number of Python communities. How could I possibly determine this? In the open source world, how do you vet someone, especially when the original maintainer is unresponsive?</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why?<br>
<br>
* Non-reply does not equal consent.<br></blockquote><div><br></div><div>That's a reasonable statement, but if this were to be held then a large number of stagnating package listings would have remained in that state.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Access to a commonly (or uncommonly) used package poses security and<br>
reliability issues.<br>
<br>
Why:<br>
<br>
Scenario 1:<br>
<br>
I could claim ownership of the redis package, providing a<br>
certain-to-fail email for the maintainers of PyPI to investigate?<br></blockquote><div><br></div><div>I attempt contact through other channels. I don't rely just on information provided by the requestor.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Scenario 2:<br>
<br>
I could claim ownership of the redis package, while Andy McCurdy<br>
(maintainer) was on vacation for two weeks, or sabbatical for six<br>
weeks. Again, I would gain access because under the current system<br>
non-reply equals consent.<br></blockquote><div><br></div><div>I tend to wait one month, but yes a six month sabbatical would be a problem. On the other hand, I do make every attempt to contact</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Reference:<br>
<br>
In ticket #407 (<a href="https://sourceforge.net/p/pypi/support-requests/407/" target="_blank">https://sourceforge.net/p/pypi/support-requests/407/</a>)<br>
someone who does not appear to be vetted managed to gain control of<br>
the (arguably) abandoned but still extremely popular<br>
django-registration on PyPI. They run one of several HUNDRED forks of<br>
django-registration, one that is arguably not the most commonly used.<br>
<br>
My concern is that as django-registration is the leading package for<br>
handling system registration for Python's most popular web framework,<br>
handing it over without a full investigation of not just the current<br>
maintainer but also the candidate maintainer is risky.<br></blockquote><div><br></div><div>And my counter is that I get a lot of these requests, I do my best to try to contact the original maintainer, and in the absence of any other information I need to take the requestor at their word. In the case of the request above, I contacted the original maintainer directly, using an address I knew to work, and received no response. To me that correlated well with the indication that he wanted nothing to do with the package any longer. Someone keen enough had come forward to provide updated versions of the package, amongst what you claim are hundreds of such forks (recognising that github forks are a very poor method to judge how engaged someone is with a project). In light of that, I granted that person permission to provided updates for that project.</div><div><br></div><div>Thanks for your thoughts. The procedure I use should be written down, I guess, but I'm the only person who follows it, so the motivation to do so is very low.</div><div><br></div><div><br></div><div> Richard</div></div></div></div>