<div dir="ltr">Yep, I get notified of comments, thanks.<div><br></div><div>I'll add information on how to start the process - I always require an issue in the support tracker.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 October 2014 18:54, holger krekel <span dir="ltr"><<a href="mailto:holger@merlinux.eu" target="_blank">holger@merlinux.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Oct 14, 2014 at 13:38 +1100, Richard Jones wrote:<br>
> Thanks for raising squatting as a concern. I have added what I think is a<br>
> reasonable method of handling squatting (or otherwise unused name<br>
> registrations):<br>
><br>
> <a href="https://docs.google.com/document/d/1elum7ENjQb0dLB4ATfYNtnXYVLUzsKacc0VWnHHJb2A/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1elum7ENjQb0dLB4ATfYNtnXYVLUzsKacc0VWnHHJb2A/edit?usp=sharing</a><br>
<br>
</span>thanks for going through the effort!<br>
<br>
I added some suggestions - do you see them in the doc?<br>
<br>
Also i'd suggest to change the order of sections, first "Proposed Process"<br>
and then Conditions of Transfer.<br>
<br>
It's a bit unclear to me how someone starts the process, i.e. applies<br>
for getting a name that is currently taken.  What about requiring that<br>
an Issue needs to be opened with the pypi tracker and the admin who does<br>
the (forceful) transfer shall close it approprirately so that we also<br>
have some permanent trail of what happened/was tried/discussed?<br>
<br>
best,<br>
holger<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
>      Richard<br>
><br>
> On 14 October 2014 12:40, Tennessee Leeuwenburg <<a href="mailto:tleeuwenburg@gmail.com">tleeuwenburg@gmail.com</a>><br>
> wrote:<br>
><br>
> > Hi all,<br>
> ><br>
> > I have just finished reading through most of the prior discussion on this<br>
> > issue, but as I read it in one sitting, I can't promise to have covered<br>
> > every nuance. I would like to propose that the pendulum has swung too far<br>
> > for some use cases.<br>
> ><br>
> > The use cases covered in that discussion appeared to me to be<br>
> >   (a) Process for not allowing takeover a not-really/not-fully abandoned<br>
> > project<br>
> >   (b) Process for taking over a (really) abandoned but useful project<br>
> >   (c) Establishing graceful handover request processes and matchmaking<br>
> ><br>
> > I would like to suggest another edge case:<br>
> >   (d) Taking over an abandoned project which does not have any code,<br>
> > hasn't been touched for years and doesn't do anything. That is to say,<br>
> > squatting.<br>
> ><br>
> > The projects which fill some use provide value to people because<br>
> > regardless of what maintainer politics may be happening, they are still<br>
> > installable, useful things.<br>
> ><br>
> > Squatter packages don't do any good to anyone. Mostly, these will have<br>
> > been created with good intentions to "get round to it" or otherwise provide<br>
> > some value to the community. However for whatever reason, they get left<br>
> > behind. If the original creator is still on email, then this can be handled<br>
> > through normal process and the wishes of the original author can be<br>
> > identified. However, I am in the middle of a situation where that's not the<br>
> > case, and the current formalities don't allow any wriggle room (as written,<br>
> > anyway).<br>
> ><br>
> > One possibility would be to allow take-over in non-contactable situations<br>
> > where the utility of the namespace is being wasted (subject to the<br>
> > administrator's interpretation). Another would be to use the "Development<br>
> > Status" flag to put different controls in place.<br>
> ><br>
> > Regardless, I am currently in a situation where I would like to register a<br>
> > particular name, and make use of it for at least somewhat valuable code.<br>
> > Someone registered the same name ages ago (over a year) and there's no code<br>
> > in it, and the github repo for the project is similarly inactive. They<br>
> > can't be reached. I've just posted  to the issue tracker in case that<br>
> > reaches them, but my hopes are not high.<br>
> ><br>
> > I think it's a shame if the policy is written such that there is no<br>
> > recourse for exceptions and no way to avoid "locking in" cruft and<br>
> > accumulation of bad packages with no clear future use. I think it's also a<br>
> > reasonable requirement that maintainers and authors be contactable (within<br>
> > some definition of time period etc)<br>
> ><br>
> > In this case, I can consider another name, of course. Unfortunately (for<br>
> > me), this whole policy discussion has only come up after I started the<br>
> > process of looking into a pypi name takeover. I've put energy into setting<br>
> > up the project with its current name, and have now put a fair bit of time<br>
> > into trying to meet everyone's needs with regards to the PyPI entry.<br>
> > Changing the pypi name means changing all kinds of other information<br>
> > systems in order to have naming consistency, it's not just a trivial matter<br>
> > for me. It's hard for me to see how anyone is benefiting from this<br>
> > situation -- the current nameholder isn't actually doing anything, and it's<br>
> > just putting the brakes on getting things done and wasting namespace.<br>
> ><br>
> > I'd appreciate it if this group could consider putting some wording around<br>
> > handling exceptional circumstances, and/or dealing with "squatter" type<br>
> > scenarios.<br>
> ><br>
> > I realise I have simplified a few things, but I did so in the interest of<br>
> > getting to what I thought the most important aspects were. Let me know if<br>
> > you'd like any more information.<br>
> ><br>
> > Regards,<br>
> > -Tennessee<br>
> ><br>
> ><br>
> > --<br>
> > --------------------------------------------------<br>
> > Tennessee Leeuwenburg<br>
> > <a href="http://myownhat.blogspot.com/" target="_blank">http://myownhat.blogspot.com/</a><br>
> > "Don't believe everything you think"<br>
> ><br>
> > _______________________________________________<br>
> > Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> > <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
> ><br>
> ><br>
<br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br>
</div></div></blockquote></div><br></div>