# Community Cloud Desktops

I propose to create an easy way for Rust community members to create a cloud machine to be used for Rust development namely: compiling, testing, and debugging the rustc compiler.

## Motivation

Time working on the Rust compiler is often spent by waiting for a build/test to run, touching the code again and rerunning. The difference between the time spent waiting and the time actually coding can be quite large depending on the amount of CPU power available and the specific kind of work being performed.

Compiling the Rust compiler from scratch on recent 4 core CPUs can easily (anecdotally measured) take up 10-15 minutes (more if LLVM is also built) with another 5-10 minutes for tests.

Some contributors do not have even this level of resources available and thus end up limiting themselves to certain subsets of rustc contributions that require less time. If we give people more resources to build the compiler, they will likely contribute more. It may also open up contribution opportunities for people who could not contribute at all before having access to such resources.

Furthermore, if we give contributors even more resources, like say a 96 core cloud machine, then

* tests take 35 seconds, and
* a build from scratch (without LLVM) takes less than 5 minutes.

Considering we process around ~300 PRs/week with an average ~20 builds/PR, the ~10 mins (or more) lost on each build, we end up with ~1000 hours (125 work days with 8h each) of contributor time lost per week.

## Details

Foundation members that offer commercial cloud services provide cloud machines in their cloud services to the Foundation. Rust team members (of any team), can then obtain access to these machines.

Ideally we’d develop some scheme to tie this to github accounts, since team membership is already managed this way. Then we could automate giving access to said machines. The exact management of the access scheme is not specified in this document, but it is important to make this process as hassle free as possible.

Once everything is established, we can start experimenting with giving access to first time contributors. Possible processes could be to tie it into `@rustbot claim` invocations on github issues, with a potential "sign-off" by a team member to protect against fraudulent use.

Every Rust developer has their own process for working with rustc and we don’t want to nudge or force them into a specific process. Thus we should not just provide fully set up machines, but also allow them to just pick a setup out of what the cloud provider offers. We should still provide ready-to-use images of common use-cases:

* the rust repo already checked out
* everything installed to immediately run x.py
* rustup installed to make working on tools easy
* cross compilation to the 32 bit variant of the host system

These images can be picked instead of a generic machine that they have to set up themselves. Additional default images can be offered if the need arises.

## Technological Details

* minimum specs: ~50 cores, 8 GB of RAM, 20 GB of disk space
* ideal specs: ~100 cores, 16+ GB of RAM, 50 GB of disk space
* this will allow developers to maintain multiple checkouts of rustc and even build them at the same time
* stretch-goals:
* auto-setup accounts with a checkout of rustc
* share computations between users via sccache
* auto-clean up unused accounts

## Situations to prepare for

* Opening up arbitrary access to computation power may see those resources abused (non-Rust work, crypto-mining)
* regular review of resource usage is usually possible in cloud services, so someone in the foundation needs to have an eye on that.
* There may be confusion about who gets access and who not. This may make people feel like they are being treated unfairly.
* People may book a machine and never really use it. This should not be a problem in most cloud systems, as not using a machine mostly doesn’t use resources.
* make sure we have such lazy machines instead of dedicated ones. Otherwise people may feel like they shouldn’t book a machine because they use it rarely.
* People may be afraid of using the service due to it being in corporate hands.
* an admin could get into their account and push to github repositories they gave their account access to
* admins could see who does what. Even if all results are public, the intermediate work is private

## Quotes

> man!, I need a faster machine to work on rustc
it is impossible to do something
I'll think about investing money on renting a server or something
everything takes years to do

> I am working on this issue and because it is a little hard for me and I need to debug code many times so I need to build every time and it takes 10 minutes on my system to build

> I had some troubles getting stuff done because my computer could not handle the heavy load of a clean rustc compile in less than 2 hours
But I have a new one now
And it's pretty fast. Not the fastest, but it should help me iterate better over the work

> Then, I learned that I need to build unoptimized LLVM to do this on my Ubuntu PC. It was very hard, I spent 2 days for this. https://internals.rust-lang.org/t/blessing-tests-for-rustc-too-hard-for-average-pc/14396

### If you want to contribute to rustc, but don't currently do, what is stopping you?

> I picked up a beginner issue once, but it took so long for me to read the instructions on bootstrapping etc that someone else submitted the PR before I could get going.
That’s when I realized for me contributing to Rustc wasn’t worth it

> frustrated because build system keeps tripping me up

> Compile times

> One of the reasons I built a workstation two years ago was so I could start contributing to rustc. I still do, but don't when e.g. using my laptop.
> builds take 45 mins on my laptop. That's a pretty slow feedback loop

> The build times for the compiler.

> the entry barrier (size, complexity, CI round trip...) is a bit high for someone having a half an hour now and then, while small libraries are OK with that.

> I only have one tiny PR merged into rustc. I'd love to contribute more but two things get in the way:
> 1) issues marked as easy and medium seem to get snapped up really quickly, so it's sometimes hard to jump in
> 2) Compile times can be a bit intense

> Hard to pick things to work on, slow compilation (e.g. php-src fully recompiles in about a minute on my machine, recompilation literally takes a couple seconds).

> Mainly time and computing power.