[Distutils] Process for taking over abandoned packages

[Tennessee Leeuwenburg]

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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141014/e629efdb/attachment.html>