[Catalog-sig] pre-PEP: transition to release-file hosting at pypi site

[Donald Stufft]

On Mar 10, 2013, at 6:41 PM, PJ Eby <pje at telecommunity.com> wrote:

> On Sun, Mar 10, 2013 at 5:16 PM, Donald Stufft <donald at stufft.io> wrote:
>> If someones release process forces PyPI to have security, uptime, and privacy issues then I'm very sorry but their release process is going to need to change. It's not fun, it's a shitty situation, but trying to bend over backwards to enable their current release processes is like trying to bend over backwards to enable people to still walk into their banks vault and grab a stack of currency.
> 
> When people in group 1 express disapproval of people in group 2, this
> creates a rallying effect among members of group 1, and a *negative*
> counter-reaction in members of group 2.
> 
> This is effective if, and *only* if, the people in group 2 have less
> power in the situation than the people in group 1.   For example, if
> co-operation from the people in group 2 are not needed in order to
> carry out the wishes of group 1.
> 
> However, in the situation under discussion, such co-operation is
> required, which means an alternative motivational strategy is
> indicated.
> 
> That strategy involves giving persons in group 2 a better reason to
> care than "because we in group 1 think you group 2 people are
> thieves."
> 
> And by better, I mean, a reason that *benefits group 2*, and more
> specifically, each individual in group 2 who chooses to co-operate.
> 
> And ideally, you work also to lower the cost of that co-operation.
> 
> That's what *this* thread was originally about (lowering the cost of
> co-operation), before these "burn the witch" sentiments started up
> again.  So, why not just step aside and let the adults go back to
> working on the actual problem?
> 
> Just kidding, of course.   ;-)  That's an example of me using the same
> type of communication style, in the opposite direction: spewing
> disapproval at something I don't like, instead of giving you a reason
> that benefits *you*, to do what I want.  See how it feels, going the
> other direction?  Did it motivate you to be helpful?  I'm guessing
> not.  ;-)
> 
> Anyway, my point is this: people don't like it one bit when you tell
> them what to do.
> 
> If you tell them, "you must do X", you get resistance.
> 
> But if you offer them a choice, "Are you going to do X or Y?", there's
> much less resistance.
> 
> And if one choice is less convenient than the other, most will pick
> the easier choice.
> 
> So, would you rather fight with developers to make them do it your
> way, or have most of them do exactly what you want and most of the
> rest get pretty close, but not have to fight with them about it?
> 
> Right now, the impression you and certain other people are giving me
> is that it is more important that whatever action we take be seen as
> censuring the practice of off-PyPI hosting, than that we actually fix
> the problems!
> 
> And it's difficult to take such a position seriously, because the
> post-hoc rationalization of harms is, well, unconvincing at best to a
> neutral party.  When PyPI was first built, it didn't *have* hosting,
> so there was nothing morally wrong about off-site hosting then.
> 
> And when hosting was first added, automated downloading didn't exist
> yet, either.  So it still wasn't wrong.
> 
> And when I added automated downloading, I made the choice to encourage
> people to collaborate by making it as easy as possible.  So offsite
> hosting still wasn't wrong, in fact it was a documented alternative.
> 
> And that's been the case for, oh, 8 years now?
> 
> So what you're actually doing isn't crusading against evil-doers, it's
> more like saying that every restaurant that isn't McDonalds should be
> immediately remodeled, because you have just noticed the shocking
> trend that hardly any of those restaurants will serve you food as
> quickly!
> 
> And that of course, the restaurant owners should undertake the
> remodeling and procedure changes, retraining, retooling, etc. at
> *their* expense, on *your* timeline.
> 
> Just so that *you*, who *chose to visit those restaurants in the first
> place*, can get your food a bit more quickly.
> 
> Sure, I know that's not how *you* see it.
> 
> But surely you can see that's how the *restaurant owners* are going to see it.
> 
> And if you want them to co-operate, it's probably going to be in your
> interest to focus your attention on their side of the equation, rather
> than on yours.  You already agree with your point of view.  They
> don't.
> 
> I realize that can be difficult to do when you have strong feelings
> about a subject.  For example, as I write this I keep backing up and
> deleting all sorts of unhelpful things I find myself wanting to say.
> ;-)
> 
> And I'm doing that because I'm consciously reminding myself that
> *getting to a solution* is more important to me than *making you feel
> bad* for being "wrong on the internet".
> 
> What's more important to you?  The *actual* state of PyPI, or the
> state of who is to be considered right or wrong?
> 
> If it's the former, you would probably find it useful to your goals,
> to please refrain from calling me and that other 10% of PyPI thieves.
> Or really any other names whatsoever, explicitly OR implicitly.
> 
> Thanks.

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. All I said was that their process needed to change, I even expressed sympathy with the fact it did need to change. 

I've never called *anyone* on this list, or on PyPI a thief. 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*.

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 believe I've said it before, but if not here it is again: I will donate *my free time* to help ANYONE who is using a release process which this change would break to engineer a new release process that has as little impact on their actual process as possible and not have all these issues for the greater Python community. And let's just be clear, I'm offering to put aside a massive list of things I need to be doing to help the very folks you're saying i'm disparaging. 

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130310/9b64073f/attachment.pgp>