4 ms·

Speaking as a historically pedantic person, correctness is often a form of perfectionism. Just gussied up. Unless you have a verifiable system all the way down

Speaking as a historically pedantic person, correctness is often a form of perfectionism. Just gussied up. Unless you have a verifiable system all the way down, you will always have bugs, crashed, and race conditions. Going all the way to 11 on trying to make it correct usually results in negligible improvement in correctness for a lot more time spent. Depends on the system of course. This is a terminal emulator, not a rocket ship. I'm not suggesting you should just have totally bug ridden code, but if you are putting people through years of in-PR iteration on a thing to achieve "correctness", either 1. Close it because you won't get what you want 2. Accept it and improve it prior to release. I'd point out: If it is really this hard for reasonable programmers to get it "correct", do you really think the people on the other side of the PR are so good at programming that they are getting it all right too?

purple_turtle 5y ago
Is it a valid reason to ignore known and found problems?
zozbot234 5y ago
"Accepting" a pull request means merging it, and broken code should not be merged. By all means feel free to propose improvements to the PR, then merge it. And if achieving a reasonably well-defined standard of correctness (i.e. avoiding complete and utter breakage) is not feasible, the PR should be scaled back until it becomes so. Start with the minimum useful change, then expand on it.
- DannyBee 5y ago
  Broken is a very loaded word. So i don't agree with this as written. If by broken you mean "does not compile or pass tests", then fine, sure. If by broken you mean "there are likely some hard issues in there", then no, i don't agree. I've watched plenty of really good software where the dev process amounts to: 1. Integrate code that is more experimental into the development trunk 2. Let people discover what is wrong with it 3. Fix and iterate it 4. Release. The approach on some open source projects amount to: 1. Refuse to integrate code until every conceivable thing is thought out and dealt with. Burn through and push away tons of contributors in the process 2. Integrate code (or sometimes just give up and throw it away!) 3. Discover there were bugs in it anyway, because no code is perfect. Fix them. 4. Release I would put money the releases put out by projects that spend years arguing to get PR's "correct" are not of any higher quality (by bug rate, etc) than the ones that accepted more experimental code and iterated it in the codebase. In fact, i'll put money they are worse. One (of many) reasons is that the former process is one where people are expected to fix bugs and issues after integration, and that their job does not end when the code is integrated. This matches reality - bugs will be found, issues will be discovered, etc. The latter process often makes people feel like once it's "ready", it's "ready", and it's done. That just doesn't end up true in practice unless it's a remarkably simple system. (or you have highly verifiable systems/process)
  - zozbot234 5y ago
    > 1. Integrate code that is more experimental into the development trunk > 2. Let people discover what is wrong with it > 3. Fix and iterate it This kind of experimentation can be done on a separate branch. There's no need to involve whoever maintains the "main" development branch until the code is reasonably OK for release. In some cases, it can be acceptable to merge code that's clearly marked as experimental into the main trunk if it's a totally separate feature that can be ensured to not affect normal use of the project. You can see this, e.g. with "nightly" Rust features, which are opt-in and clearly separate from the "stable" language. But this is not very feasible in something like a terminal emulator, for obvious reasons.
    - DannyBee 5y ago
      Yeah, that's the party line for sure, but the end effectiveness of waiting until "it's okay for release" is low. You will never reach that point. Most experimental branches basically see no use outside of who is developing them. So a lot of time you are only really getting them to the point they pass existing tests, and maybe whatever additional testing the person writing the code is doing. As a result it's really rare that code got enough testing on that branch that it was "ready for release" when it was integrated. Show me software done this way, and i'll show you software released with lots of bugs and point releases :) One of these development processes admits that's true and integrates it at some earlier point and accepts it will take more work despite that. I'm also not sure what "no need to involve whoever maintains the main branch" means. Software development is a team sport. If you don't want it to be, don't accept contributions (no judgement, i'm serious).
      - abstract_put 5y ago
        Acknowledging my bias towards correctness first (or a harness for explicitly experimenting), I think your step 3 ("3. Fix and iterate it") is rarely ever done and that absence puts people off. In the corporate environments I work in, the PR sets the standard for what is acceptable and there's vanishingly little motivation to fix anything that isn't blowing up a high profile client. Basically mini tragedy of the commons. I wouldn't be surprised if an aspect of this is "I don't trust you'll iterate and fix this, and I don't want to, so please make sure this is correct". I would expect a contributor with a long/trust-filled relationship to the maintainer to have much more leeway for not-exactly-perfect contributions.

purple_turtle 5y ago

Is it a valid reason to ignore known and found problems?

zozbot234 5y ago

"Accepting" a pull request means merging it, and broken code should not be merged. By all means feel free to propose improvements to the PR, then merge it. And if achieving a reasonably well-defined standard of correctness (i.e. avoiding complete and utter breakage) is not feasible, the PR should be scaled back until it becomes so. Start with the minimum useful change, then expand on it.

DannyBee 5y ago
Broken is a very loaded word. So i don't agree with this as written. If by broken you mean "does not compile or pass tests", then fine, sure. If by broken you mean "there are likely some hard issues in there", then no, i don't agree. I've watched plenty of really good software where the dev process amounts to: 1. Integrate code that is more experimental into the development trunk 2. Let people discover what is wrong with it 3. Fix and iterate it 4. Release. The approach on some open source projects amount to: 1. Refuse to integrate code until every conceivable thing is thought out and dealt with. Burn through and push away tons of contributors in the process 2. Integrate code (or sometimes just give up and throw it away!) 3. Discover there were bugs in it anyway, because no code is perfect. Fix them. 4. Release I would put money the releases put out by projects that spend years arguing to get PR's "correct" are not of any higher quality (by bug rate, etc) than the ones that accepted more experimental code and iterated it in the codebase. In fact, i'll put money they are worse. One (of many) reasons is that the former process is one where people are expected to fix bugs and issues after integration, and that their job does not end when the code is integrated. This matches reality - bugs will be found, issues will be discovered, etc. The latter process often makes people feel like once it's "ready", it's "ready", and it's done. That just doesn't end up true in practice unless it's a remarkably simple system. (or you have highly verifiable systems/process)
- zozbot234 5y ago
  > 1. Integrate code that is more experimental into the development trunk > 2. Let people discover what is wrong with it > 3. Fix and iterate it This kind of experimentation can be done on a separate branch. There's no need to involve whoever maintains the "main" development branch until the code is reasonably OK for release. In some cases, it can be acceptable to merge code that's clearly marked as experimental into the main trunk if it's a totally separate feature that can be ensured to not affect normal use of the project. You can see this, e.g. with "nightly" Rust features, which are opt-in and clearly separate from the "stable" language. But this is not very feasible in something like a terminal emulator, for obvious reasons.
  - DannyBee 5y ago
    Yeah, that's the party line for sure, but the end effectiveness of waiting until "it's okay for release" is low. You will never reach that point. Most experimental branches basically see no use outside of who is developing them. So a lot of time you are only really getting them to the point they pass existing tests, and maybe whatever additional testing the person writing the code is doing. As a result it's really rare that code got enough testing on that branch that it was "ready for release" when it was integrated. Show me software done this way, and i'll show you software released with lots of bugs and point releases :) One of these development processes admits that's true and integrates it at some earlier point and accepts it will take more work despite that. I'm also not sure what "no need to involve whoever maintains the main branch" means. Software development is a team sport. If you don't want it to be, don't accept contributions (no judgement, i'm serious).
    - abstract_put 5y ago
      Acknowledging my bias towards correctness first (or a harness for explicitly experimenting), I think your step 3 ("3. Fix and iterate it") is rarely ever done and that absence puts people off. In the corporate environments I work in, the PR sets the standard for what is acceptable and there's vanishingly little motivation to fix anything that isn't blowing up a high profile client. Basically mini tragedy of the commons. I wouldn't be surprised if an aspect of this is "I don't trust you'll iterate and fix this, and I don't want to, so please make sure this is correct". I would expect a contributor with a long/trust-filled relationship to the maintainer to have much more leeway for not-exactly-perfect contributions.