Yep, I get notified of comments, thanks. I'll add information on how to start the process - I always require an issue in the support tracker.
On 14 October 2014 18:54, holger krekel <hol...@merlinux.eu> wrote: > 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 <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 > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
