[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