Instead of overtaking, how about clearly marking packages as abandoned/maintained clearly pointing out the mark was imposed by community action and listing potential/primary replacements
this would have the possibility of also supporting normal abandonment when people voluntary stop maintenance and cannot find a successor its important that community imposed abandonment is not simply removable by doing a minor "noop"-release, after all if abandonment had to be applied by proof of 3rd party, there is need of proof of continued maintenance pip could warn on installation/update -- Ronny Am 18.04.2016 um 23:31 schrieb Ian Cordasco: > On Mon, Apr 18, 2016 at 4:16 PM, Chris Barker <chris.bar...@noaa.gov> wrote: >> You've made a strong case, and this is probably not where PyPi should go -- >> but it would hardly be a disaster: >> >>> The idea of expiring out names has been brought up recently to resolve an >>> issue of two packages, one popular and large; another someone's weekend >>> project. >> >> The issue here is not that it's a weekend project, but that it may be an >> abandoned project. I don't think anyone suggest that we should have a >> popularity or quality test to see who gets to trump whom with name >> allocation -- I sure didn't. >> >> Which is quite relevant to below: >> >>> 1. PyYAML is a package that would be de-registered in such a scheme. It >>> is a highly used, extremely popular, package that unserializes text into >>> arbitrary python objects. It is a trusted package... and one that hasn't >>> been active in ages. >> >> and you don't think ANYONE would be willing to take on the miniscule amount >> of work to maintain the name? Plus there would be any number of other >> schemes for determining whether a project name is abandoned. > I have in fact offered but the author refuses to accept help from > anyone. They're also the author of the C library (libyaml) and they do > not maintain that either. It's actually quite frustrating as someone > who wants to fix some of the numerous bugs in the library + improve it > and add support for YAML 1.2 which is years old at this point. > >>> 2. the package tooling already assumes that names will always point to >>> one, and only one package. ever. until the heat death of the universe or >>> the death of the language whichever is first. >> >> IIUC, the current scheme allows for a name to be "taken over" by a new >> package if the original author so desires -- i.e. if the current owner of >> the mypy name was happy to relinquish it, then "pip install mypy" would get >> users something totally different 6 months from now. So no -- we don't >> currently guarantee anything about future use of names. Other that that the >> original author can do whatever they want with it. >> >>> 3. Who in the PSF really wants that bureaucratic nightmare of arbitrating >>> cases when this inevitably messes up, be this system manual or automatic? >> >> I think bureaucratic nightmare is pretty hyperbolic, but yes, there would be >> some overhead, for sure. And given that no one has the time and motivation >> to even maintain PyPi at this point -- this will probably kill the idea >> altogether. >> >> >>> To the specifics of the mypy-lang package that brought this up... It's >>> like naming your company "Yahoo", and getting upset that yahoo.com is >>> getting a bump in traffic because of your popularity. >> >> Again - this is not about minor weekend projects not be "important". It's >> about potential abandonware -- with domain registration, "Yahoo" can offer >> to buy the domain from the current holder, or, if the current owner has >> abandoned it, it will go into the public pool again when they stop paying to >> maintain the registration. >> >> -CHB >> >> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R (206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> chris.bar...@noaa.gov >> >> _______________________________________________ >> 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
