4 ms·
Automation would be a primary reason. Gerrit and Rietveld [1] allow Google to build bots and tooling to land commits, allocate build infrastructure resources fo
by nishs 10y ago
Automation would be a primary reason. Gerrit and Rietveld [1] allow Google to build bots and tooling to land commits, allocate build infrastructure resources for tests, and rollback tree-breaking changes. GitHub would not be quite so hackable.
The automation would be even more important for a codebase like Chromium that receives 5-8 change lists every minute [2].
[1] https://github.com/rietveld-codereview/rietveld https://github.com/rietveld-codereview/rietveld
[2] https://codereview.chromium.org/ https://codereview.chromium.org/
- steveklabnik 10y agoGitHub absolutely is scriptable this way; we at the Rust project use various bots extensibly for landing commits, build infrastructure for tests, welcoming new contributors... We don't need to roll back tree-breaking changes because the bots are the only ones allowed to land changes in the first place, and they make sure all tests pass before they land. There's no reason a bot couldn't do this, though.
- nishs 10y agoApologies for the misleading GitHub portion in my previous comment. I agree, Rust is wonderfully maintained on GitHub. That said, Google might consider it easier to work with Gerrit, Rietveld, Gitiles, etc. because they can work with the source code of these projects directly, than having to write potentially ugly code to work around missing pieces in GitHub's API. I'd love to learn whether a large scale project such as Rust has run into these issues with GitHub.
- steveklabnik 10y agoIt's all good! I didn't think you were saying Rust was somehow mis-managed. There's some stuff that could be nicer with GitHub generally, but I don't think having the source would make it any easier to build out this automation; github's API is pretty solid.