Making sure the repository doesn't break, automatically - https://people.gnome.org/~federico/blog/making-sure-the-repository-doesnt-break.html
@federicomena you probably want to point people to bors-ng; it has a much more scalable algorithm (optimistic batches with bisection) https://bors.tech/
@graydon what could make one repo not scale? Long build times / lots of contributors / things like that?
@federicomena Yes, cycle time and commit volume. Speaking from experience these become significant enough bottlenecks that people who are cynical or impatient about the plan will argue for switching back to "merge first, test later". It's astounding but I've seen this play out repeatedly now. Like people who "don't need type systems" and use compile time as their lever in the argument. Failure to do whole system accounting on development process, time lost to broken trees.
@graydon Preach it. It's wanting to go back to not wearing safety equipment.
Do you know how it "felt" when Rust switched from the original Bors to whatever new implementation? I kind of want to use homu-gitlab as soon as possible if it already would work for gitlab.gnome.org, instead of shaving the yak of porting bors-ng to gitlab.
I guess I haven't used what Rust uses from a maintainer's viewpoint; I just like the "tree never breaks" mechanics.
@federicomena No, I have no idea about homu; they switched to it after I left. As far as I know it's fine. Original-generation bors was about as stupid and crude as I could make it. Stateless cron job every 5 minutes.
@graydon thanks! The stateless model *is* very appealing.