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 <tleeuwenb...@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@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
