> On Sep 22, 2014, at 9:25 AM, Antoine Pitrou <anto...@python.org> wrote: > > Donald Stufft <donald <at> stufft.io> writes: >> >> The problem with cruft is they make it more difficult to find things for end >> users who often times don't know what they are looking for. This is >> especially >> bad when you have a once popular library/tool for which the maintainer is no >> longer available. It's already a daunting task for someone to select a >> library >> that does something they need to do if they aren’t already familiar with the >> ecosystem. Adding "landmines" in the form of projects which look to solve > their >> problem but where there is no-one to help them if they run into a bug or who >> can release a bug fix is fairly unfriendly. > > It's unfriendly if you consider that it's PyPI's job to select packages for > users. But it does not seem to be going in that direction (see e.g. the > absence > of ratings or comments, after a brief appearance).
It's not PyPI's job to "select packages for users", but it is PyPI's job to make it as easy as possible to discover relevant packages and provide them with as much information as is reasonable about that package so that the user can select for themselves which packages to use. I'm not going to get into the debacle that was the ratings system but the lack or existence of such a feature does not change the role of PyPI in any way. > > Usually people get their recommendations through the community. > If you want to help people through PyPI, you may want to add a friendly, > non-scary warning to the PyPI pages of projects which haven't been updated > for 24+ months. Sure, I never stated that transfering ownership was the only possible or even the best way to handle cruft. Personally I'm on the fence about what the best way to handle it is, there are benefits to transfering ownership and downsides. I was only stating what the problem with cruft is. > >> Circling back to django-registration, we can see the extra confusion this can >> cause when a maintainer stops maintaining a popular package. You end up with >> a multitude of forks, each slightly incompatible and with different features, >> bugs, etc. > > It's inherent to the problem of unmaintained packages. But why would PyPI have > any authority over who steps over? PyPI does not have any legitimity to steer > those projects. It's not even a controlled software distribution; it's just > an index. PyPI inherinently has complete control over who owns what name on PyPI. What limits are put on that control are a matter of policy. It is no less valid for PyPI to transfer ownership than it is for PyPI not to transfer ownership as a matter of Policy. As I said earlier, PyPI isn't hardly the only system like itself that exercises authority over the project names in the case of abandoned projects. 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. There are also cases where it makes *obvious* sense not to do a transfer, such as if some random person asked to transfer pip to their name because we hadn't had a release in a little under 6 months. Given that there are cases where it makes sense to do a transfer, and cases where it doesn't make sense to do a transfer the important part is to figure out, as a matter of policy, where those lines are. To that I think it'd be great to have a documented procedure for doing transfers and even rough guidelines as to when it makes sense to do it, but that ultimately it would be a decision up to the maintainers of PyPI (currently Richard and myself, though I rarely get involved in that side of things). This sort of "BDFL"-esque thing is primarily because edge cases happen often, although the common cases should be able to be handled by the rough guidelines, and because ultimately you have to trust the PyPI maintainers anyways for any reasonable use of PyPI. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
