Putting bors on a PIP


#21

Yes. The way I envisage this working is similar to how tools like Cargo and the RLS work today - we run a subset of appropriate tests when a PR is merged to the std repo (for example), and then the full set of tests when we update the sub-module/crate dep in the main repo (which would take as long as today, but would happen much less frequently).

Of course merging updated std into the main repo might not work and someone would have to then fix up the std repo. So we’d be trading that bit of manual work for the improved turnover (and other benefits). I don’t think we sacrifice correctness. Of course the ‘fixup’ work is happening today, but it is happening in individual PRs, in the 2-stage model, it would happen in bigger batches and would require some dedicated attention from somebody.


#22

Yeah, this gets close to the “Lieutenant” model, and it’s their job to deal with integration stuff. This is what happens already with me and the books.

For example, when updating the books for 1.26, a bunch of links were broken: https://github.com/rust-lang/rust/pull/49318#issuecomment-375850762

So I went and fixed them, and then updated the integration PR to pass.


#23

Ah I see. This indeed doesn’t sacrifice correctness, but also doesn’t try to tackle the build time timeouts problem (which is fair). I suppose this would potentially be used in combination with moving to a CI provider with longer timeouts - because there are less individual merges to master, longer builds aren’t a problem.


#24

This is also how std::arch, std::simd, and libc are set up and it is really nice.

I worry a bit about duplicating the CI infrastructure throughout all of these, but until now we have managed this just fine.


closed #25

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.