4 ms·

So, first of all I disagree. Just because something is not prevented by technical means doesn't make it allowed. That goes for all things in life, outside of a

So, first of all I disagree. Just because something is not prevented by technical means doesn't make it allowed. That goes for all things in life, outside of a supermax prison. And after being asked twice by another maintainer (one of the two current maintainers (none of which are her), as I read it) to please follow the procedures, she tells him to fuck off and overrides him. And after all that she does actually write something intended to look like an apology. So what does that mean? Either she disagrees with you, and indeed she should have followed procedures, or all she's apologizing for is "sorry you got so upset", which more of a taunt than an apology. No, actually. Contrary to what cryptocurrency people would have you believe, there are other and more effective ways to prevent undesirable behaviour than technical means, for the vast majority of behaviour.

jimnotgym 5y ago
..and further it is not possible to discern properly the relationship between a project and a contributor just because there is a time gap. If I wrote a project completely myself up to version 1.1 and then allowed other maintainers on to it who had taken it to version 1.2 I might feel I can merge whatever I like even after a gap. Not saying that is what happened here, just saying that it is impossible to discern from that discussion
pnut 5y ago
Isn't this situation a counterexample though? Nontechnical ways to prevent behaviour were attempted, and failed. For distributed software development processes, the only thing that works are hard boundaries. No hard boundary -> implicitly tolerated. For instance, "the vast majority of behaviour" includes every line of code in a repo. The only viable way of preventing undesirable behaviour of a software system is to enforce passing tests before merging. A mandatory technological safety net baked into the developer's workflow. All of these boundaries are to prevent human error propagating to production. Merging changes without review shouldn't be possible.
- knorker 5y ago
  > Isn't this situation a counterexample though? Nontechnical ways to prevent behaviour were attempted, and failed. Not really. Just like shoplifting isn't a motivator for putting everything behind the counter in a store. The cure could be worse than the disease. > For distributed software development processes, the only thing that works are hard boundaries. Definitely not true. Opensource has existed for a really long time without a two-key system. Many projects (besides this one) still have big sets of people with commit bits. I'd go so far as to say that almost all projects with a core team size greater than one has some amount of this, with very very few exceptions. Not everyone needs protections as if they are covered by Sarbanes-Oxley (SOX). And these projects work just fine. In fact, it's not even desirable in most cases. You have to take development velocity into account, too. "It must never be possible to unilaterally commit to the main repo" is not the value the project brings to the world. It's a means to deliver the actual value. And it's not the only one. So there are always tradeoffs. Having worked under mandated requirements (legal and contractual) such as this, I can tell you that it's not without big costs, costs that opensource projects would rather spend on other things. Especially since it's detectable. Preventable is usually not worth the extra costs. > No hard boundary -> implicitly tolerated. Of course that's not true. Not in any context. You don't go to someone's house and flip their furniture, and say that not only was the furniture not nailed down, it wasn't even part of the ToS for entering your house, and in any case the door was unlocked. A project without a CoC is obviously not implying that you can be a nazi or sexually harass. "What is not prevented is permitted" has never been true in the whole history of humanity, and there have always been repercussions for what you did. I've been a sysadmin with root access. That doesn't in any way make it implicitly tolerated that I read people's emails and home directories. > Merging changes without review shouldn't be possible. Ideally yes. But it's more convenience than security. E.g. your example about having pre-merge testing decreases the toil of maintainers having to deal with test-breaking code being merged. I.e. having to roll it back, and deal with any merge conflicts during rollbacks. But by your logic of "no hard boundary -> implicitly tolerated" this means I could change the code to detect if it's running in a test, and do something else. There's no hard boundary, but will obviously not be tolerated.
  - pnut 5y ago
    We're going to have to agree to disagree, if you are arguing against mandatory code reviews in software projects. Beyond the obvious sanity checks, they exist for establishing collective consent, and knowledge sharing - these are responsibilities that increase with seniority, not decrease. Junior people should never be permitted to sidestep the process, and senior people must be leaders and set an example. But it's a big world, so do your thing.
xwdv 5y ago
You are wrong. It takes no effort to enforce reviews for pull requests. So why not just do it? If that’s the desired behavior, why not just enforce it as the desired behavior? Relying on people to remember rules or adhere to some informal policy isn’t scalable, and complicates onboarding for new maintainers who may not be aware of the repo’s “culture”. We are tech people, do things technically.
- joeberon 5y ago
  Almost a dystopian, kafkaesque view of the world
- knorker 5y ago
  > Relying on people to remember rules or adhere to some informal policy isn’t scalable Is that the case here? She was asked twice to follow the formal procedure. She basically replied "fuck off". > It takes no effort to enforce reviews for pull requests. So why not just do it? Fair enough. Devil's advocate here: If they had then they wouldn't have found out that they can't trust this person to act in the project's best interests. But yeah. Seems reasonable to me to just flip the bit, if indeed for them it's that simple. But there will NEVER be that easy a fix for all issues. Edit: It seems it may be more complicated than this. Other commenters have said that this project was moved into a Github enterprise account, which granted this person god-like powers. If so, then at the very least this means that she exploited a temporary security vulnerability, where she found herself with god like access she was not supposed to have according to the project maintainers and policy. It's also not scalable to "just never have a security gap", which is also one of the many many arguments against cryptocurrencies. "Prevent-only" just does not scale. > We are tech people, do things technically. Hmm... I'm trying to not say "I used to think that, but then I grew up", because I don't intend it as an insult. Running a project, and more true the larger it is, is not as much technical work. There will always exist the technical possibility to do the wrong thing (except in a supermax prison). And even when possible, most technical means are just not worth it. We can't all develop software like the space industry[1]. It's just not worth it. Especially when the problems are of the kind that can be undone, like this one was (rollback PR). [1] https://www.nap.edu/read/2222/chapter/5 https://www.nap.edu/read/2222/chapter/5

jimnotgym 5y ago

..and further it is not possible to discern properly the relationship between a project and a contributor just because there is a time gap. If I wrote a project completely myself up to version 1.1 and then allowed other maintainers on to it who had taken it to version 1.2 I might feel I can merge whatever I like even after a gap. Not saying that is what happened here, just saying that it is impossible to discern from that discussion

pnut 5y ago

Isn't this situation a counterexample though? Nontechnical ways to prevent behaviour were attempted, and failed. For distributed software development processes, the only thing that works are hard boundaries. No hard boundary -> implicitly tolerated. For instance, "the vast majority of behaviour" includes every line of code in a repo. The only viable way of preventing undesirable behaviour of a software system is to enforce passing tests before merging. A mandatory technological safety net baked into the developer's workflow. All of these boundaries are to prevent human error propagating to production. Merging changes without review shouldn't be possible.

knorker 5y ago
> Isn't this situation a counterexample though? Nontechnical ways to prevent behaviour were attempted, and failed. Not really. Just like shoplifting isn't a motivator for putting everything behind the counter in a store. The cure could be worse than the disease. > For distributed software development processes, the only thing that works are hard boundaries. Definitely not true. Opensource has existed for a really long time without a two-key system. Many projects (besides this one) still have big sets of people with commit bits. I'd go so far as to say that almost all projects with a core team size greater than one has some amount of this, with very very few exceptions. Not everyone needs protections as if they are covered by Sarbanes-Oxley (SOX). And these projects work just fine. In fact, it's not even desirable in most cases. You have to take development velocity into account, too. "It must never be possible to unilaterally commit to the main repo" is not the value the project brings to the world. It's a means to deliver the actual value. And it's not the only one. So there are always tradeoffs. Having worked under mandated requirements (legal and contractual) such as this, I can tell you that it's not without big costs, costs that opensource projects would rather spend on other things. Especially since it's detectable. Preventable is usually not worth the extra costs. > No hard boundary -> implicitly tolerated. Of course that's not true. Not in any context. You don't go to someone's house and flip their furniture, and say that not only was the furniture not nailed down, it wasn't even part of the ToS for entering your house, and in any case the door was unlocked. A project without a CoC is obviously not implying that you can be a nazi or sexually harass. "What is not prevented is permitted" has never been true in the whole history of humanity, and there have always been repercussions for what you did. I've been a sysadmin with root access. That doesn't in any way make it implicitly tolerated that I read people's emails and home directories. > Merging changes without review shouldn't be possible. Ideally yes. But it's more convenience than security. E.g. your example about having pre-merge testing decreases the toil of maintainers having to deal with test-breaking code being merged. I.e. having to roll it back, and deal with any merge conflicts during rollbacks. But by your logic of "no hard boundary -> implicitly tolerated" this means I could change the code to detect if it's running in a test, and do something else. There's no hard boundary, but will obviously not be tolerated.
- pnut 5y ago
  We're going to have to agree to disagree, if you are arguing against mandatory code reviews in software projects. Beyond the obvious sanity checks, they exist for establishing collective consent, and knowledge sharing - these are responsibilities that increase with seniority, not decrease. Junior people should never be permitted to sidestep the process, and senior people must be leaders and set an example. But it's a big world, so do your thing.

xwdv 5y ago

You are wrong. It takes no effort to enforce reviews for pull requests. So why not just do it? If that’s the desired behavior, why not just enforce it as the desired behavior? Relying on people to remember rules or adhere to some informal policy isn’t scalable, and complicates onboarding for new maintainers who may not be aware of the repo’s “culture”. We are tech people, do things technically.

joeberon 5y ago
Almost a dystopian, kafkaesque view of the world
knorker 5y ago
> Relying on people to remember rules or adhere to some informal policy isn’t scalable Is that the case here? She was asked twice to follow the formal procedure. She basically replied "fuck off". > It takes no effort to enforce reviews for pull requests. So why not just do it? Fair enough. Devil's advocate here: If they had then they wouldn't have found out that they can't trust this person to act in the project's best interests. But yeah. Seems reasonable to me to just flip the bit, if indeed for them it's that simple. But there will NEVER be that easy a fix for all issues. Edit: It seems it may be more complicated than this. Other commenters have said that this project was moved into a Github enterprise account, which granted this person god-like powers. If so, then at the very least this means that she exploited a temporary security vulnerability, where she found herself with god like access she was not supposed to have according to the project maintainers and policy. It's also not scalable to "just never have a security gap", which is also one of the many many arguments against cryptocurrencies. "Prevent-only" just does not scale. > We are tech people, do things technically. Hmm... I'm trying to not say "I used to think that, but then I grew up", because I don't intend it as an insult. Running a project, and more true the larger it is, is not as much technical work. There will always exist the technical possibility to do the wrong thing (except in a supermax prison). And even when possible, most technical means are just not worth it. We can't all develop software like the space industry[1]. It's just not worth it. Especially when the problems are of the kind that can be undone, like this one was (rollback PR). [1] https://www.nap.edu/read/2222/chapter/5 https://www.nap.edu/read/2222/chapter/5