[Distutils] Create formal process for claiming 'abandoned' packages

Richard Jones richard at python.org
Fri Sep 19 23:55:13 CEST 2014


On 20 September 2014 04:47, Daniel Greenfeld <pydanny at gmail.com> wrote:

> In order to claim a package as being abandoned it should undergo a
> formal process that includes:
>
> * Placement on a PUBLIC list of packages under review for a grace
> period to be determined by this discussion
>

This is not done at present. Can you suggest a public forum that would
reach a useful audience?



> * Formal attempts via email and social media (twitter, github, et al)
> to contact the maintainer.
>

This is done at present, using the contact details registered with pypi. Or
other contact methods if that fails.

I always default to asking the current maintainer of a package to transfer
it to a new maintainer.



> * Investigation of the claimant for the rights to the package. The
> parties attempting to claim a package may not be the best
> representatives of the community behind that package, or the Python
> community in general.
>

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?



> Why?
>
> * Non-reply does not equal consent.
>

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.



> * Access to a commonly (or uncommonly) used package poses security and
> reliability issues.
>
> Why:
>
> Scenario 1:
>
> I could claim ownership of the redis package, providing a
> certain-to-fail email for the maintainers of PyPI to investigate?
>

I attempt contact through other channels. I don't rely just on information
provided by the requestor.



> Scenario 2:
>
> I could claim ownership of the redis package, while Andy McCurdy
> (maintainer) was on vacation for two weeks, or sabbatical for six
> weeks. Again, I would gain access because under the current system
> non-reply equals consent.
>

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



> Reference:
>
> In ticket #407 (https://sourceforge.net/p/pypi/support-requests/407/)
> someone who does not appear to be vetted managed to gain control of
> the (arguably) abandoned but still extremely popular
> django-registration on PyPI. They run one of several HUNDRED forks of
> django-registration, one that is arguably not the most commonly used.
>
> My concern is that as django-registration is the leading package for
> handling system registration for Python's most popular web framework,
> handing it over without a full investigation of not just the current
> maintainer but also the candidate maintainer is risky.
>

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.

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.


      Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140920/7df43b26/attachment.html>


More information about the Distutils-SIG mailing list