<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 12, 2016, at 9:54 PM, Donald Stufft <<a href="mailto:donald@stufft.io" class="">donald@stufft.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jul 12, 2016, at 4:45 PM, Glyph Lefkowitz <<a href="mailto:glyph@twistedmatrix.com" class="">glyph@twistedmatrix.com</a>> wrote:<br class=""><br class="">My feeling is that there should be a "dead man's switch" sort of mechanism for this. Require manual intervention from at least one package owner at least once a year. I believe if you dig around in the archives there's been quite a bit of discussion around messaging to package owners and that sort of thing - and the main sticking point is that someone needs to volunteer to do the work on Warehouse. Are you that person? :)<br class=""></blockquote><br class=""><br class="">I suspect any change like this will require some sort of PEP or something similar to it. It’s something that I think is going to hard to get just right (if it’s something we want to do at all).<br class=""><br class="">Software can be “finished” without needing more releases,</div></div></blockquote><div><br class=""></div><div>"The software isn't finished until the last user is dead." :-)</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">and sometimes projects stop getting updates until the maintainer has more time (or a new maintainer comes along).</div></div></blockquote><div><br class=""></div><div>Yes; the whole point here is to have some way for people to know that a new maintainer is needed.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">An example is setuptools which had no releases between Oct 2009 and Jun 2013.</div></div></blockquote><div><br class=""></div><div>Arguably setuptools _was_ badly broken though, and if it had been obvious earlier on that it was in a bad situation perhaps we'd be further along by now :-).</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Another nice example is ``wincertstore`` which has had two releases one in 2013 and one in 2014 and is one of the most downloaded projects on PyPI. It doesn’t need any updates because it’s just a wrapper around Windows APIs via ctypes.<br class=""></div></div></blockquote><div><br class=""></div><div>Except it does need testing against new versions of Python. No Python :: 3.5 classifier on it, for example! And right at the top of its description, a security fix.</div><div><br class=""></div><div>The point of such a switch is to be able to push it and respond; not to tell the maintainer "you have to do a new release!" but rather to prompt the maintainer to explicitly acknowledge "the reason I have not done a new release is not that I haven't been paying attention; I am alive, I'm paying attention, and we don't need any maintenance, someone is still watching".</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Another thing we need to be careful about is what do we do once said dead man’s switch triggers? We can’t just release the package to allow anyone to register it, that’s just pointing a security shaped footgun at the foot of every person using that project? It doesn’t make sense to block new uploads for that project since there’s no point to disallowing new uploads. Flagging it to allow someone to “take over” (possibly with some sort of review) has some of the security shaped footguns as well as a problem with deciding who to trust with a name or not.<br class=""></div></div></blockquote></div><br class=""><div class="">The primary thing would be to have a banner on the page and a warning from `pip install´. Those of us close to the heart of the Python community already have various ways of reading the tea leaves to know that things are likely to be unmaintained or bitrotting; the main purpose of such a feature would be to have an automated way for people who <i class="">don't</i> personally know all the prominent package authors and see them at conferences and meetups all the time to get this information. For example: nobody should be using PIL, they should be using pillow. Yet there's no way for a new user to figure this out by just looking at <a href="https://pypi.io/project/PIL/" class="">https://pypi.io/project/PIL/</a> :).</div><div class=""><br class=""></div><div class="">I think that the adjudication process for stealing a name from an existing owner is something that still bears discussion, but separately. Whatever that process is, you'd have to go through it fully after a package becomes thusly "abandoned", and for the reasons you cite, it absolutely should not be automated. Perhaps it shouldn't even be the way to deal with it - maybe the most you should be able to do in this case is to expand the "this is unmaintained" warning with a pointer to a different replacement name.</div><div class=""><br class=""></div><div class="">-glyph</div><div class=""><br class=""></div></body></html>