4 ms·

Bors when introduced at my workplace was summarily disabled after 2 separate incidents where it was improperly applying commit messages (which we patched intern

by omeze 7y ago

Bors when introduced at my workplace was summarily disabled after 2 separate incidents where it was improperly applying commit messages (which we patched internally) and improperly applying patches (at which point we disabled it and explored other solutions). Combined with the merge latency overhead, I would be extremely hesitant to advocate running it at scale.

chrisseaton 7y ago
> Bors when introduced at my workplace was summarily disabled after 2 separate incidents where it was improperly applying commit messages Seems a bit extreme to discard something after finding two bugs. Could you have fixed them instead?
- draw_down 7y ago
  Nope, that happening once is bad enough. Those aren't bugs like "oh shoot, my icon is the wrong color". It's really, really important that source control is not lying to you, or things will get very difficult very quickly.
- BiteCode_dev 7y ago
  The problem is not the bugs, it's that it was probably recommended to them as a reliable solution, loosing them hours of work. This can't build trust, especially for such an important part of infrastructure: you'll always wonder when it's going to hit you next.
- omeze 7y ago
  We did fix one bug, but after the 2nd incident decided that using a tool that silently corrupts your repository is not worth the marginal benefit it provides against alternative more naive solutions. Most companies run post-merge checks so in the event of a bad merge, the offending commit can be isolated and reverted, or have a cron running at a regular cadence to isolate the issue to a set of commits. Having your repo reflect developer’s patches is really table stakes for a tool like this anyway.
metajack 7y ago
At this point there are like 4 implementations of Graydon's bors. Which one did you use? The Servo and Rust projects have used a bors* for many years and have had few problems. * Servo uses the https://github.com/servo/homu https://github.com/servo/homu fork of the Homu rewrite of Graydon's original code, and Rust uses a slightly different fork at https://github.com/rust-lang/homu https://github.com/rust-lang/homu.

by omeze 7y ago

chrisseaton 7y ago

> Bors when introduced at my workplace was summarily disabled after 2 separate incidents where it was improperly applying commit messages Seems a bit extreme to discard something after finding two bugs. Could you have fixed them instead?

draw_down 7y ago
Nope, that happening once is bad enough. Those aren't bugs like "oh shoot, my icon is the wrong color". It's really, really important that source control is not lying to you, or things will get very difficult very quickly.
BiteCode_dev 7y ago
The problem is not the bugs, it's that it was probably recommended to them as a reliable solution, loosing them hours of work. This can't build trust, especially for such an important part of infrastructure: you'll always wonder when it's going to hit you next.
omeze 7y ago
We did fix one bug, but after the 2nd incident decided that using a tool that silently corrupts your repository is not worth the marginal benefit it provides against alternative more naive solutions. Most companies run post-merge checks so in the event of a bad merge, the offending commit can be isolated and reverted, or have a cron running at a regular cadence to isolate the issue to a set of commits. Having your repo reflect developer’s patches is really table stakes for a tool like this anyway.

metajack 7y ago

At this point there are like 4 implementations of Graydon's bors. Which one did you use? The Servo and Rust projects have used a bors* for many years and have had few problems. * Servo uses the https://github.com/servo/homu https://github.com/servo/homu fork of the Homu rewrite of Graydon's original code, and Rust uses a slightly different fork at https://github.com/rust-lang/homu https://github.com/rust-lang/homu.