On 23 Sep 2014 00:19, "Antoine Pitrou" <email@example.com> wrote:
> Donald Stufft <donald <at> stufft.io> writes:
> > PyPI inherinently has complete control over who owns what name on PyPI.
> Political authority does not derive from technical control, though.
> > As Toshio said that are situations where it makes *obvious* sense to transfer
> > ownership of a project. Using Django as an pretty good example here, There are
> > four people able to make releases there, until fairly recently there were only
> > two if I recall. I don't think anyone would be against PyPI transfering
> > ownership of Django to another active core developer of Django in the event
> > that all of the people with permissions on PyPI were gone in some fashion.
> Assuming the remaining Django core developers agree on it, then, yes, that
> can make sense. That's because they are the primary authors of the project
> (even though they might not have been listed as such on PyPI).
> The case people are worried about is whether someone who is not part of the
> original project author(s) or maintainer(s) can get assigned the PyPI project.
> In that case people should use one of the forks; there's no reason for PyPI
> to crown a successor.
That's why I consider it important to get the original project's issue tracker involved in the transfer process. I'd also be OK with a process that required an affirmative "Yes" from the project community, defaulting to "No transfer" in the case of a lack of response.
Transfers are most needed for highly active projects where a fork could have a lot of ripple effects. I think it's reasonable to interpret "nobody cared enough to say yes or no" as "nobody cares enough for a transfer to be needed - just fork it rather than claiming the name".
Distutils-SIG maillist - Distutils-SIG@python.org