[Distutils] A process for removal of PyPi entries

holger krekel holger at merlinux.eu
Sat Jun 1 08:48:07 CEST 2013


On Fri, May 31, 2013 at 15:18 +0200, Lennart Regebro wrote:
> On Fri, May 31, 2013 at 3:09 PM, holger krekel <holger at 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
> 


More information about the Distutils-SIG mailing list