[Distutils] Process for taking over abandoned packages

[holger krekel]

On Tue, Oct 14, 2014 at 13:38 +1100, Richard Jones wrote:
> 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

thanks for going through the effort!

I added some suggestions - do you see them in the doc?

Also i'd suggest to change the order of sections, first "Proposed Process"
and then Conditions of Transfer.

It's a bit unclear to me how someone starts the process, i.e. applies
for getting a name that is currently taken.  What about requiring that
an Issue needs to be opened with the pypi tracker and the admin who does
the (forceful) transfer shall close it approprirately so that we also
have some permanent trail of what happened/was tried/discussed?

best,
holger


> 
>      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
> >
> >

> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig