[Distutils] Process for taking over abandoned packages

[Richard Jones]

Thanks for raising squatting as a concern. I have added what I think is a
reasonable method of handling squatting (or otherwise unused name
registrations):

https://docs.google.com/document/d/1elum7ENjQb0dLB4ATfYNtnXYVLUzsKacc0VWnHHJb2A/edit?usp=sharing


     Richard

On 14 October 2014 12:40, Tennessee Leeuwenburg <tleeuwenburg at gmail.com>
wrote:

> Hi all,
>
> I have just finished reading through most of the prior discussion on this
> issue, but as I read it in one sitting, I can't promise to have covered
> every nuance. I would like to propose that the pendulum has swung too far
> for some use cases.
>
> The use cases covered in that discussion appeared to me to be
>   (a) Process for not allowing takeover a not-really/not-fully abandoned
> project
>   (b) Process for taking over a (really) abandoned but useful project
>   (c) Establishing graceful handover request processes and matchmaking
>
> I would like to suggest another edge case:
>   (d) Taking over an abandoned project which does not have any code,
> hasn't been touched for years and doesn't do anything. That is to say,
> squatting.
>
> The projects which fill some use provide value to people because
> regardless of what maintainer politics may be happening, they are still
> installable, useful things.
>
> Squatter packages don't do any good to anyone. Mostly, these will have
> been created with good intentions to "get round to it" or otherwise provide
> some value to the community. However for whatever reason, they get left
> behind. If the original creator is still on email, then this can be handled
> through normal process and the wishes of the original author can be
> identified. However, I am in the middle of a situation where that's not the
> case, and the current formalities don't allow any wriggle room (as written,
> anyway).
>
> One possibility would be to allow take-over in non-contactable situations
> where the utility of the namespace is being wasted (subject to the
> administrator's interpretation). Another would be to use the "Development
> Status" flag to put different controls in place.
>
> Regardless, I am currently in a situation where I would like to register a
> particular name, and make use of it for at least somewhat valuable code.
> Someone registered the same name ages ago (over a year) and there's no code
> in it, and the github repo for the project is similarly inactive. They
> can't be reached. I've just posted  to the issue tracker in case that
> reaches them, but my hopes are not high.
>
> I think it's a shame if the policy is written such that there is no
> recourse for exceptions and no way to avoid "locking in" cruft and
> accumulation of bad packages with no clear future use. I think it's also a
> reasonable requirement that maintainers and authors be contactable (within
> some definition of time period etc)
>
> In this case, I can consider another name, of course. Unfortunately (for
> me), this whole policy discussion has only come up after I started the
> process of looking into a pypi name takeover. I've put energy into setting
> up the project with its current name, and have now put a fair bit of time
> into trying to meet everyone's needs with regards to the PyPI entry.
> Changing the pypi name means changing all kinds of other information
> systems in order to have naming consistency, it's not just a trivial matter
> for me. It's hard for me to see how anyone is benefiting from this
> situation -- the current nameholder isn't actually doing anything, and it's
> just putting the brakes on getting things done and wasting namespace.
>
> I'd appreciate it if this group could consider putting some wording around
> handling exceptional circumstances, and/or dealing with "squatter" type
> scenarios.
>
> I realise I have simplified a few things, but I did so in the interest of
> getting to what I thought the most important aspects were. Let me know if
> you'd like any more information.
>
> Regards,
> -Tennessee
>
>
> --
> --------------------------------------------------
> Tennessee Leeuwenburg
> http://myownhat.blogspot.com/
> "Don't believe everything you think"
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141014/86482cdf/attachment-0001.html>