On Sat, Sep 20, 2014 at 12:30 AM, John Wong firstname.lastname@example.org wrote:
TL;DR version: I think
- an option to enroll in automatic ownership transfer
- an option to promote Request for Adoption
- don't transfer unless there are no releases on the index
will be reasonable to me.
On Fri, Sep 19, 2014 at 9:26 PM, Richard Jones email@example.com wrote:
In light of this specific case, I have an additional change that I think I'll implement to attempt to prevent it again: In the instances where the current owner is unresponsive to my attempts to contact them, *and* the project has releases in the index, I will not transfer ownership. In the cases where no releases have been made I will continue to transfer ownership.
I believe this is the best solution, and frankly, people in the OSS world has been forking all these years should someone disagree with the upstream or just believe they are better off with the fork. I am not a lawyer, but one has to look at any legal issue with ownership transfer. I am not trying to scare anyone, but the way I see ownership transfer (or even modifying the index on behalf of me) is the same as asking Twitter or Github to grant me a username simply because the account has zero activity.
Between transferring ownership automatically after N trials and the above, I choose the above. Note not everyone is on Github, twitter. Email, er, email send/receive can go wrong.
As a somewhat extreme but not entirely rare example, Satoshi Nakamoto and Bitcoin would be an interesting argument. If Bitcoin was published as a package on PyPI, should someone just go and ask for transfer? We know this person shared his codes and the person disappeared. Is Bitcoin mission-critical? People downloaded the code, fork it and started building a community on their own. What I am illustrating here is that not everyone can be in touch. There are people who choose to remain anonymous, or away from popular social network.
Toshio Kuratomi firstname.lastname@example.org wrote:
But there are also security concerns with letting a package bitrot on pypi.
Again, I think that people should simply fork. The best we can do is simply prevent the packages from being downloaded again. Basically, shield all the packages from public. We preserve what people did and had. We can post a notice so the public knows what is going on.
Surely it sucks to have to use a fork when Django or Requests are forked and now everyone has to call it something different and rewrite their code. But that's the beginning of a new chapter. The community has to be reformed. It sucks but I think it is better in the long run. You don't have to argue with the original owner anymore in theory.
Last, I think it is reasonable to add Request for Adoption to PyPI. Owners who feel obligated to step down can promote the intent over PyPI
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I, for one, am happy that this conversation is happening because I wasn't aware of other communities that did this (but was aware that it happened on PyPI). That said, I would really appreciate people's suggestions be contained to improving the process, not towards modifying PyPI. At this point, as I understand it, PyPI is incredibly hard to modify safely for a number of reasons that others are likely better to speak to. Warehouse has a clear definition, design, and goals and I don't know if adding these on after-the-fact in a semi-haphazard way will improve anything. The more useful discussion right now will be to talk about process and how we can improve it and help Richard with it.