4 ms·

Isn't this situation a counterexample though? Nontechnical ways to prevent behaviour were attempted, and failed. For distributed software development processes

by 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.
  - knorker 5y ago
    No, I think as soon as a project has two people who care about it and will reliably review, it should be turned on as mandatory. But there will always be a way for one of these two to go around the process, if they really want to. Otherwise you have to plan for what happens if anybody becomes unavailable. But it's clearly not "the only thing that works". E.g. AFAIK OpenBSD still just gives core team the commit bit, and don't work on a "prevent" basis for enforcement. And if not OpenBSD anymore, then this has at least been the default model of CVS for over 30 years. It clearly does, in fact, work just fine. Now, enforced code review is better. So I agree with all you said in this comment. But it's not as simple as what you said before. But short of SOX-compliant stuff and very strict environments, there will always be people with "god" powers. As I understand it the PR author here could have turned off code review, merged, and turned it back on. And with the attitude she showed in the comment saying "yeah thanks this is my project so I do what I want", clearly "doing the right thing" was not on the radar. It didn't serve to remind her, because she knew. She acted as if "above the law" deliberately. So in almost all cases yes. In this case no.

by pnut 5y ago

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.
- knorker 5y ago
  No, I think as soon as a project has two people who care about it and will reliably review, it should be turned on as mandatory. But there will always be a way for one of these two to go around the process, if they really want to. Otherwise you have to plan for what happens if anybody becomes unavailable. But it's clearly not "the only thing that works". E.g. AFAIK OpenBSD still just gives core team the commit bit, and don't work on a "prevent" basis for enforcement. And if not OpenBSD anymore, then this has at least been the default model of CVS for over 30 years. It clearly does, in fact, work just fine. Now, enforced code review is better. So I agree with all you said in this comment. But it's not as simple as what you said before. But short of SOX-compliant stuff and very strict environments, there will always be people with "god" powers. As I understand it the PR author here could have turned off code review, merged, and turned it back on. And with the attitude she showed in the comment saying "yeah thanks this is my project so I do what I want", clearly "doing the right thing" was not on the radar. It didn't serve to remind her, because she knew. She acted as if "above the law" deliberately. So in almost all cases yes. In this case no.