[geofft]

This is the one true way to do things, of course (https://graydon2.dreamwidth.org/1597.html), but besides the "why not use bors/homu" question - what prevents GitHub or GitLab from building this in?

I hope we get to a world one day where a standard feature of all pull-request-ish platforms is that merges end up on a task queue, CI runs on the merge, and the merge only happens if CI passes. It doesn't seem like a terribly difficult feature to build in and the potential UX seems much nicer - e.g., just like there's "squash and merge" and "rebase and merge" buttons and the repo admin can require them over normal merges, there could be an "enqueue for merge" / "enqueue for rebase" / etc. button.

(Maybe your goal is to get us to that world via acquisition, which would be great!)

[notriddle]

That's the world I'm hoping for, as well. I'm the lead contributor to bors-ng.

Like Steve Jobs criticizing Dropbox, I think that bors is a feature, not a product. If GitHub integrated merge trains, I would probably just call it quits and put bors-ng on feature freeze, maintaining it only enough to make sure it stays working and patched for vulnerabilities while everybody migrates off of it.

There are a few reasons for this, but mostly it's because of all the unfixable bugs and limitations that are caused because bors-ng isn't a GitHub feature.

* I can't squash PRs while still having them show up as purple in the GitHub UI. GitHub just doesn't let you do that.

* The CI configuration needs to be partially duplicated between the CI system itself and bors.toml. To fix this, bors would need to implement its own GitHub Actions workflow file parser. If implementing the CODEOWNERS file is any indication, that basically means reverse-engineering GitHub's behavior, because you can bet your life their documentation won't cover every possible corner case.

* Some pull request review features need to be duplicated between GitHub itself and bors-ng, like pre-checks and CODEOWNERS, because there's no stable API to get that information.

* Bors-ng isn't allowed to modify GitHub Workflow files [1]. They just don't let GitHub Apps do that.

* Bors-ng can't always tell whether a CI error should cause the PR to be rejected, or if it's just going to be retried later [2]. To fix this, it basically need to know incident information for the CI provider, which basically means it would have to have a hotline to their ops teams, which I don't.

[1]: This is because bors-ng is an app, rather than a machine user. It would be fixable, but fixing it would make it harder to deploy.

[2]: https://twitter.com/AstraLuma/status/1300797343135137796

These are the biggest problems I have with bors-ng right now. Some of these are theoretically solveable, if you're willing to do way more work than I am, but some of them are truly impossible for anyone but GitHub to solve, and all of them are easier for GitHub to solve than they are for anyone else because they have infrastructure powers that we don't have.

It's honestly a little demoralizing.

[ankitdce]

That's a great question. FWIW Gitlab does have merge train with similar baseline functionality. There's two part answer to your question: - even though it's trivial from the face of it, since we specialize in merging process, we are able to provide much more complex workflows, such as batch mode. - starting with MQ, our goal is continue focusing in engineering productivity and build as we understand the use cases better. We imagine a world where every team has the toolset that is built internally by developer productivity teams at the likes of Google, FB. We have to still start somewhere right :)