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

[Donald Stufft]

> On Sep 21, 2014, at 7:06 PM, Antoine Pitrou <antoine at python.org> wrote:
> 
> Ethan Furman <ethan <at> stoneleaf.us> writes:
>> On 09/19/2014 04:13 PM, Alex Gaynor wrote:
>>> 
>>> I **strongly** concur with James here. This has flagrantly violated my
> trust in
>>> PyPI.
>>> 
>>> I would much rather packages not be reclaimed than need to think about
> whether
>>> I trust the PyPI maintainers to do it.
>> 
>> Having PyPI become full of cruft is not a tenable situation.
> 
> What is the problem with "cruft" exactly?
> 
> I'm opposed to the idea that a package may be "transferred" to someone
> else without any explicit authorization from the original maintainer(s)
> (or author(s)). It is not a matter of waiting time or tools. It is morally
> unacceptable.
> 
> If you want to maintain a package and the maintainer doesn't reply,
> there is a solution: fork the package (under a new name).
> 
> If you don't want to see "stale" packages, there is a solution:
> build an optional filter into PyPI that only shows packages
> which have received an update in the last 12/24/36 months.
> 
> Regards
> 
> Antoine.

The problem with cruft is they make it more difficult to find things for end
users who often times don't know what they are looking for. This is especially
bad when you have a once popular library/tool for which the maintainer is no
longer available. It's already a daunting task for someone to select a library
that does something they need to do if they aren’t already familiar with the
ecosystem. Adding "landmines" in the form of projects which look to solve their
problem but where there is no-one to help them if they run into a bug or who
can release a bug fix is fairly unfriendly.

Circling back to django-registration, we can see the extra confusion this can
cause when a maintainer stops maintaining a popular package. You end up with
a multitude of forks, each slightly incompatible and with different features,
bugs, etc. Now in the case of django-registration the author *is* available
and wishes to retain control of django-registration, so that's fine, but you
can hopefully see the sort of confusion that a maintainer going missing can
cause?

This isn't a problem that can be automatically solved because there's no
programatic way to differentiate between "stable" and "abandoned", especially
when you want to consider "abandoned but the author wants to maintain control",
"abandoned but the author is willing to give it up", and "abandoned and the
author is no longer available" differently.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140922/16f5e329/attachment.html>