On Sun, Mar 10, 2013 at 8:25 PM, Donald Stufft <don...@stufft.io> wrote: > I don't think anyone is bad here, nor am I arguing against any particular > person or group of people. I'm arguing against a practice and a system. > You're going out of your way to find excuses to throw all sorts of stop > energy here.
Calling a legitimate disagreement with your point of view "stop energy" seems inappropriate to me, since my issue is with you derailing the topic of how to get people to *voluntarily* migrate to a better situation than the present one, and to develop tools for that process. The only thing I wish you to stop is the repeated assertion without proof that 1) external links must go *and* 2) this must be an enforced directive rather than a (highly-encouraged) option. I have even gone so far as to suggest, earlier in this thread, what evidence I would find at least suggestive of your POV. But your response to that and prior challenges to those assertions, has been simply to move your goalpost. E.g. from "current uptime is bad" to "any uptime lower than PyPI's is totally unacceptable". I, on the other hand, have moved in the direction of *your* proposals repeatedly, making adjustments as I find actually-convincing evidence and/or reasoning, or find ways to deal with the issues. I have compromised quite a bit. (And have already spent a fair amount of time writing setuptools code to lay a foundation for these changes.) You, as far as I can tell, have not moved your position in the slightest. Which of these is "stop energy"? It is not the case that external links must be removed from PyPI in order to ensure security, or uptime. And it is *especially* not the case that you are the BDFL of uptime. You're definitely not the BDFL of uptime for any given project hosted on PyPI, that you *voluntarily choose* to make a part of your build process. If your primary argument is that project X must host its files on PyPI because of your build process, then I think you misunderstand open source, and also the part where you *chose* to make it part of your build process. It certainly doesn't give you the right to force projects Y, Z, and Q -- that you don't even use! -- to also host their projects on PyPI, because project X -- the one you do use -- has a slow or unreliable file host! It seems disingenuous to then shfit the argument back to security when challenged on uptime, and back to uptime when challenged on security. We've looped back and forth over those for some time: when I point out that wheels have signatures which will make off-site hosting relatively unimportant to the security picture, you jump back to talking about uptime. When I point out that uptime is a consensual factor that in no way justifies legislating what other people can do with their projects, you go back to talking about security. Make up your mind. What problem are you actually trying to solve? (I expect your response on wheels to be that wheels aren't there yet, etc., but that isn't actually a response to the objection unless you're going to change your position to, "okay, external links to file formats that can be signed can stay," or something of that sort. Otherwise, you're not actually compromising, just using the fact that wheels aren't in common use yet as an argument to keep the position you started with.) > My analogy served only to put into light that the system that I'm trying to > change is insecure, just like allowing anyone to walk into a bank vault and > pick up money would be insecure. I fully believe that the people using such a > system are completely trustworthy people. But just because *they* are > trustworthy doesn't mean that a system which allows *anyone* to attack other > Python developers is *ok*. And my analogy served only to put into light the part where you're insisting that one group of people change for the benefit of a group which is already benefiting from their pre-existing generosity. That being said, I do see that I could have misinterpreted the intent of your analogy -- it sounded like you were saying that the developers who host off-PyPI were thieves walking into your bank and taking your money (i.e., analogizing theft with inconveniencing you by making your builds fail or run slowly). Though to be honest, I still don't comprehend how else to make any kind of sense to that analogy in its original context. Who is the bank? Whose money is being taken? The whole thing is utterly confusing to me if I try to take it any other way than the way I did, because it doesn't seem to have any other simple 1:1 mapping to the situation, as far as I can see. Your explanation seems terribly abstract and tortured to me, as far as analogies go. > When discussing security of a system it's necessary to divorce yourself from > the implementations of things. When you get wrapped up in the implementation > you turn things into a Us vs Them game (as evidenced by several of your > messages) instead of discussing the merits of the various systems and which > ones serve the greatest needs of the community the best. I think you've got things backwards here. It's you who's been arguing that the solution to the problem of "improved uptime and security" is best implemented by "ban all non-PyPI hosting". It is I who has been arguing that this is a premature judgment and rush to implementation, without considering all of the design angles. And I am the one asking you to stop insisting on this one implementation and state your *actual* problem with external links. (By which I mean, a problem stated such that, if you're given a solution that *doesn't* involve banning them from PyPI, you aren't going to rejigger the problem statement so that it once again requires banning. That's moving the goalposts, and that's what keeps happening in this discussion, at least as far as I can see. I, on the other hand, have given you my actual problem with your proposal, and I have not moved *my* goalposts. Instead, I've moved towards your position, more than once. But I've moved as far towards it as I can go at this time, without you providing any additional evidence or explanation or *some* kind of engagement with the points that I've raised above that you've previously ignored, in this thread and others.) _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
