​​Rust All Hands 2018 - Infra Team

​​Meetings

​​Tuesday - 2 hours

  • ​​‘Extreme’ bors planning - how are we going to fix bors cycle times, both short term and create a plan to last us through the next year, possibly spend up to an hour on this alone to make sure we have concrete directions in mind coming out of it.
  • ​​Intending to invite participants from other teams to participate
  • ​​Priorities for the next year
  • ​​Support the Rust 2018 roadmap
  • ​​Maintain Rust infrastructure
  • ​​Monitoring
  • ​​CI
  • ​​Crater
  • ​​Bots
  • ​​How to drum up interest?
  • ​​Badges for crater
​​
​​Meeting notes
  • ​​Two ‘types’ of contributors
  • ​​New: want a great experience for new devs, review and land quickly
  • ​​Established: don’t want rebase hell, want to get it in
  • ​​Linux kernel model only works because fewer tests
  • ​​Need to be able to scale for increasing number of PRs
  • ​​libstd can probably never move out of tree
  • ​​for a submodule merge, use compiler artifacts from the previous builds
  • ​​We know the compiler hasn't changed, so can just reuse it from last time rather than rebuild
  • ​​May update Cargo.lock, so would also need to split up Cargo.lock
  • ​​Some subtleties here, e.g. no artifacts produced so would need to reupload from last time
  • ​​Solution part 1: make less go through bors
  • ​​Do more testing beforehand (Windows, aux, std if std PR)
  • ​​Fill in the gaps when builders are idle
  • ​​Solution part 2: need to fix timeouts
  • ​​Look at the timing information and fix it
  • ​​Idea: if only 1 builder out of 60 timed out, merge (need dist builders for artifacts)
  • ​​Idea: Use build stages on travis to increase the timeout (appveyor?)
  • ​​Idea: Move the timing out builders to alternative CI
  • ​​Beg Linux/Windows machines from Google?
  • ​​Also storage? Would it be faster to store in Google’s cloud? Should run benchmarks beforehand
  • ​​TaskCluster has OSX machines we could shift onto if necessary
  • ​​Change: rollup prioritisation
  • ​​Highest priority of the highest PR in the queue
  • ​​How to handle ‘monthly merge madness’ where the queue gets very long
  • ​​Need to keep an eye on this
  • ​​PR priority of PR number, homu prioritises by lowest rather than highest
  • ​​Submodule splitting is happening anyway, the pain of integration is shouldered by splitters
  • ​​E.g. docs
  • ​​Hides contribution increases of the rust project - this is the way we’re scaling already
  • ​​Plan to tackle build times head on
  • ​​Timing information for all steps
  • ​​Use the graph with timing info to identify critical path of whole build