On Fri, May 31, 2013 at 15:18 +0200, Lennart Regebro wrote:
On Fri, May 31, 2013 at 3:09 PM, holger krekel <holger@merlinux.eu> wrote:
I think there should be a PEP regulating the removal and the "taking over" process for packages. Your considerations make sense to me there. ASFAIK Perl has such policies a decade or so. Probably makes sense to use their provisions as a blue print. Such a PEP should contain a list of projects that are to be removed retro-actively if they don't comply within 6 months or so. I think the barrier shouldn't be too high, a valid email address and/or release activity are a good minimum. And it should be a short PEP :)
I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user.
For other cases there should also be a manual way or removing packages on the discretion of PyPI maintainers, as well as giving owner access to packages whose owner is unreachable (I think there may already exist a process for that).
I'd like to argue in the same direction. While technical means to detect unmaintained or empty registrations are worthwhile to consdier i believe we should put emphasize on the human process. If you look at perl's guidelines for taking over maintenance here: http://www.cpan.org/misc/cpan-faq.html#How_adopt_module it's focused on the human communication process which i think is the right way to go about it. Any technical automated solution can probably be abused easily, given ill intentions, see the DNS for reference. A PEP should list criteria but leave decisions ultimately to a trusted board/admins which should maintain a public changelog of their actions. Those criteria should of course be automatically analyzed and used as input for the human process if possible. best, holger
//Lennart