[Distutils] Process for taking over abandoned packages

[Richard Jones]

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 <holger at 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 <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141015/b85f333c/attachment-0001.html>