bors-ng is a rewrite of bors/homu in Elixir. Interesting things:
Concerns: Will the algorithm work well with the flaky CI infrastructure?
From what I can tell, the automatic rollup is decent, but in my opinion not all that good for us. We build artifacts on every PR merge which are then used for bisection and performance reporting; this makes rollups of PRs which have potential to change perf and introduce accidental breaking changes problematic for us. I donāt think thereās really any major advantage beyond the automatic rollups to using bors-ng other than the possibly better handling of various states due to more active maintenance.
So are you having problems do to the manual rollups we currently do? Why would procedurally generated rollups be different?
When doing manual rollups we (or at least I) try to limit to only simple or less likely to be the bisection cause PRs. Itās possibly not the best approach, but it does work. As far as I can tell, bors-ng by-default rolls up all PRs, not just those marked with rollup. This may be incorrect though.
Youāre correct.
If you want the artifact cache to work the same way as itās been working, youāre going to want parallel building, which sounds like something Travis CI would love 
(but Iām going to guess that it would be within Rustās budget, if the code were implemented).
BTW, I think Rust would also like the (admittedly very simple, so it shouldn't be that hard to add to homu) "try arguments." Basically, you leave a command like this:
bors try --platform=linux
And bors-ng writes this into the commit message:
Try #NNN: --platform=linux
Your test harness can then use the git cli to grab (and sed to parse?) the commit message and use it to determine which platform to test on. Rust already does this kind of stuff to limit the subset of the test suite that's run when PRs are opened.
Of course, the ideal setup would throw a second Integration into the mix, to make this work:
bors try --cargobomb
That would probably require a custom webhook, since cargobomb is not going to run within Travis.
Indeed parallel building is the best way to speed up testing and leave the artifacts intact. This Is best described in the documentation for zuul. But as alexcrichton pointed out āRight now we unfortunately just donāt have capacityā.
The discussion on adding procedurally generated rollups to the existing infrastructure is at homu/issues/102. Although sofar it is mostly me working conceptually. I would love to hear what people are concerned about and what strategies they would or would not find acceptable.
Also one day Iād love to see this in rust, but those projects are still pretty far off.
I still find that automatic rollup would be much better, because:
But well, @notriddle I found the lack of priority a blocker for migration. Letās get it implemented soon. bors-ng is really well maintained 
The described batching algorithm does seem like it has a high potential to not work well for Rust, with our long turnaround times, and high intermittent rates. Iād be more comfortable adopting it if it supported our existing workflow and let us gradually experiment with others.
If bors-ng is going to be maintained, and it can support our workflow, and somebody is willing to do the work of the transition, and preferably if it can remain under the venerable āborsā account, then it might be worth pursuing. Weāve long wanted to replace homu. Iām glad somebody has finally done the work - I didnāt realize it was ongoing.
Hereās what it looks like in action: https://bors-app.herokuapp.com/
Sadly thereās no activity in the queue.
Also re the batching algorithm, we often use bors in ways where we probably donāt want batching. For example, just last week I threw a PR at bors several times, fully expecting it to fail, just so I could see what the CI windows results would be.
It would be prudent to identify our current bors wishlist, and see how bors-ng will address them. Weāve often discussed changes to homu we want, but donāt make because nobody wants to hack on homu.
Hereās an example of what it looks like in RO mode. The PR to enable this is in review, now.
Edit: PR landed and deployed. Hereās the queues for:
In the context of finding enough people who know the language and are willing to improve the bors-ng codebase, is the usage of elixir expected to be a benefit, a detractor, or neutral?
Compared to Rust, I expect it to be neutral as far as finding developers. Compared to Python, however, it probably makes it harder to find developers.
I am working on understanding how homu works so I can hack on it. I am starting with batching, I am trying to design something very small and conservative to start with.
If we have a wishlist, then letās get it together so persons can help.
As bors-ng seams better maintained, when it meets most of the requirements then Iād advocate for the switch. Not that I have much say in the matter.
It does prioritization now. Shout-out to @khodzha for implementing it, BTW!
@alexcrichton I think itās a good time to migrate to bors-ng. Are you interested in rolling it out on all nursery repositories, or even cargo?
Itās already being adopted at crates.io. Be patient; thereās still a few missing features before the bigger rust-lang repos can use it.
any progress ?