Move Fast and Fix Things
githubengineering.com
Move Fast and Fix Things
1–10 of 95 posts
Re: Move Fast and Fix Things
#2Wow, strange that people weren't reporting these merge issues when they were clearly impacting people.
Re: Move Fast and Fix Things
#3I am trying to understand why the new merge method needed to be tested online via experiment. Both correctness and performance of the new merge method could have been tested offline working with snapshots (backups) of repos. Could a github engineer shed more light here?
Re: Move Fast and Fix Things
#4I am trying to understand why the new merge method needed to be tested online via experiment. Both correctness and performance of the new merge method could have been tested offline working with snapshots (backups) of repos. Could a github engineer shed more light here?
maybe they just do everything in production. "move fast and fix things"
Re: Move Fast and Fix Things
#5I am trying to understand why the new merge method needed to be tested online via experiment. Both correctness and performance of the new merge method could have been tested offline working with snapshots (backups) of repos. Could a github engineer shed more light here?
That is harder than just running the experiment online.
Re: Move Fast and Fix Things
#6Wow, strange that people weren't reporting these merge issues when they were clearly impacting people.
I haven't read the whole article yet, so I might have missed something; but how do we know that people weren't reporting these issues?
I've always had to report issues to GitHub via email as they do not have a public issue tracker (something I've always found a bit ironic).
Re: Move Fast and Fix Things
#7Wow, strange that people weren't reporting these merge issues when they were clearly impacting people.
My read of the article implies that they were running the new method on the side, and comparing the results to the old method that was still running in production. They got to 100% before they actually pulled the lever on what customers would use.
Edit: Ah, I see - talking about the Git bugs, not the differences . I’m actually not surprised that “256 (or a multiple) merge conflicts” was never noticed (or at least root-caused and fixed) by the entire git community.
Wonderful ability to use a large userbase as a giant fuzzer.
Re: Move Fast and Fix Things
#8This is inspiring reading. One may not actually need the ability to deploy 60 times a day in order to refactor and experiment this effectively, but it's clearly a culture that will keep velocity high for the long-term.
Re: Move Fast and Fix Things
#9Wow, strange that people weren't reporting these merge issues when they were clearly impacting people.
I haven't read the whole article yet, so I might have missed something; but how do we know that people weren't reporting these issues? I've always had to report issues to GitHub via email as they do not have a public issue tracker (something I've always found a bit ironic).
It's interesting that git is the same. [EDIT:] ...in that all issues and PRs are emailed rather than entered into a web app.
Re: Move Fast and Fix Things
#10I am trying to understand why the new merge method needed to be tested online via experiment. Both correctness and performance of the new merge method could have been tested offline working with snapshots (backups) of repos. Could a github engineer shed more light here?
Speculation, but if they already have the infrastructure to run the test online then it was probably easier than building one-time-use tools to test backups.