On Sat, Sep 20, 2014 at 1:30 AM, John Wong <gokoproj...@gmail.com> wrote: > Hi all. > > 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 <rich...@python.org> 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. > This is a great example, however, I think that you're assuming that the answer to the question of whether services like twitter and github (and facebook and email service providers and many other service-customer relationships) should sometimes grant username takeovers is 100% no and I don't believe that's the case. I mean, in the past year there was a loud outcry about facebook not being willing to grant access to an account where the user had died and their family wanted access to the data so as to preserve it. Facebook eventually granted access in that case. Email has historically been transferred quite frequently. When you quit a job or leave a university your email address is often taken from you and, when someone with a similar name or inclination arrives, that address can be given to someone else.
> Toshio Kuratomi <a.bad...@gmail.com> 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. > I'm on the fence over the model that I think you've got in your head here but I think it's more important to talk about why I think demanding people fork is the wrong path to take in my example which I think is much more cut and dried. Let's say you belong to a large project with 50 committers and a user's mailing list that numbers in the thousands of subscribers. The project owns a domain name with a large website and shoot, maybe they even have a legal body that serves as a place to take donations, register trademarks and so forth. You happen to be the release manager. You've been with the project since it was a small 5 person endeavour. While everyone else was busy coding, you specialized in deployment, installation, and, of course, creating a tarball to upload to pypi on every release. People may oca casionally think that they should help you out but hey, you've always done it, no one has reason to complain, and besides, there's this really important bug that they should be working on fixing instead.... So then you die. It's unexpected. Hit by a bus. Eaten by a velociraptor. You know the various hypothetical scenarios. Well, the project is still vibrant. It still has 49 committers. It's still the owner of a trademark and a domain name. It still has thousands of users. Now that it's a necessity, it can even find that has other people to volunteer to replace you as release manager. What it doesn't have, is permission to upload to pypi anymore. I think if someone asked to transfer ownership to another member of the upstream project had the time to research this they'd have no trouble at all deciding that the right course of action would be to transfer ownership. In this scenario all of the facts point towards the upstream being the people who should have rights to upload to pypi and they simply didn't have the foresight to assure that they wouldn't lose that right through an accident. Now what if we start taking some of the features of the scenario away? What if there wasn't a foundation? A trademark? A domain name? What if the release manager disappeared from the internetz and no one knew if he was alive or not? What if he was on a two week vacation but the project found that they had to make an unexpected release to fix to a horrendous security exploit ASAP? I think that pypi works best if we can be accommodating to these circumstances when there's a clear story of whether the requestor is a valid person to take ownership. We can quibble about the criteria for determining that validity but I think we should keep in forefront of our minds that all of our goals is to give the user the code they are searching for and not some other code. In some cases this will mean that we shouldn't transfer ownership when the new owner is a random fork but in others it will mean that we should transfer ownership because everyone expects the code to be this specific fork. -Toshio _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
