> On Nov 29, 2017, at 11:10 PM, Sumana Harihareswara <s...@changeset.nyc> wrote: > > While getting up to speed on Warehouse I saw how many package transfer > requests are waiting for PEP 541[0] to be accepted, so I thought it > might be helpful to round up what I see as the outstanding questions. > > 1) Usage criteria for abandoned projects. > >> The tricky part there is that "being used" is a tough concept to >> define. Over what time period? What amount of downloading counts as >> "used"?-- Chris Rose[1] > > Perhaps a month? suggests Matthias Bussonnier.[2] > > The ensuing discussion includes thoughts on locking old versions of the > project[3]; as I see it, that's a potential feature request for > Warehouse, but not something to build into this PEP. (Similarly, Nick > Timkovich's idea of "salting" hot-button names on PyPI so it isn't > possible to register projects like "android"[4] is a feature idea I like > but I think this PEP does not need to wait for it.)
A month seems reasonable to me, though I don’t know how much we can or should define “being used”. For instance, every package in existence is going to be downloaded via mirroring, so we can’t go by pure download counts (and some mirrors just use pip to do their downloading) and we’re going to need to interpret the download counts to some degree to try and gauge “usage”. Ultimately I think the underlying question we’re answering is whether names on PyPI are a community good or a personal good, and this PEP more or less states they are a community good and attempts to outlay the situations in which it is good for the community to have a name reassigned. Given that, I think the guideline of “not being used over a month” is a reasonable one, and that lets the admins interpret the download counts in that light. > > 2) A few copyedits from Chris Barker.[5] > > 3) "How would I, for example, start the process of flagging a > project as abandoned?" -- Nick Timkovich[6] > > It seems to me that the PEP's wording in "Removal of an abandoned > project" says we'll allow transfer of abandoned projects but will not > remove them only for being abandoned. However, the PEP currently doesn't > include a "where to file a ticket" line in that section (as it does in > "Invalid projects"). Also, if there's some other reason we should be > willing to remove abandoned projects even without a transfer, e.g., the > project has a critical security flaw, we should say that somewhere in > this PEP or in a different policy document. I do not think the PEP needs to include this, since the PEP itself won’t be the end user facing documentation for this, but is rather the proposal that this is how we do these things, and there will be a page on PyPI that has user facing policy sans rationale, history, etc that will also include stuff like actual procedure for contacting admins to get something looked at under this policy. > > There is one item Łukasz mentioned this in the "I decided to not > otherwise touch on:" list regarding the revision on January 14th[7] that > I think deserves one more chance for discussion. :) A few people brought > up making the reachability criteria and instructions crisper. Generally I think that package authors should be responsible for ensuring that there is some mechanism on PyPI that we can use to communicate with them. I’m down with adding more features to Warehouse to make this more likely, but ultimately I think it boils down to authors should expect to have an email on file with PyPI we can reach them at for important communication, or they should not be surprised when things happen they were not aware of. > >> Regarding reachability: contact attempts should also include the >> relevant project's issue tracker if attempts at private contact have >> failed. >> >> This step is important as it allows a project's *user* community to >> respond, even if the person that actually pushes the buttons to >> upload new releases to PyPI is out of contact for some reason. > -- Nick Coghlan[8] > > Nick Timkovich also suggested some specific instructions[9] that would > help set expectations to, among other things, reassure maintainers about > the length of offline vacations they can take without worrying about > having their packages usurped. :) > > I'm totally fine with folks saying to me: no, these are all addressed, > or not important enough to slow adoption of this PEP. In which case, > yay, I hope Donald can accept it and we can start processing the backlog. The current timeline is 6 weeks, so that is effectively the window that people are expected to be available sometime every 6 weeks. I don’t have a good sense for if that is reasonable or not, if people think it should be longer we can easily do longer. My personal life I rarely take any vacation or am unavailable for rarely more than 24h, so for me personally 6 weeks would be an eternity, but if folks feel that a 6+ week vacation is something we want to support, then we can trivially adjust this upwards. > > > [0] https://www.python.org/dev/peps/pep-0541/ > [1] https://mail.python.org/pipermail/distutils-sig/2017-January/030017.html > [2] https://mail.python.org/pipermail/distutils-sig/2017-January/030020.html > [3] https://mail.python.org/pipermail/distutils-sig/2017-January/030034.html > [4] https://mail.python.org/pipermail/distutils-sig/2017-January/030006.html > [5] > https://mail.python.org/pipermail/distutils-sig/2017-September/031517.html > [6] https://mail.python.org/pipermail/distutils-sig/2017-January/030005.html > [7] https://mail.python.org/pipermail/distutils-sig/2017-January/030009.html > [8] https://mail.python.org/pipermail/distutils-sig/2017-January/030008.html > [9] https://mail.python.org/pipermail/distutils-sig/2017-January/030005.html > > -- > Sumana Harihareswara > Changeset Consulting > https://changeset.nyc > _______________________________________________ > 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
