Mark Rousskov

I would probably suggest that we serve the logs from crater.rust-lang.org and maybe have ~1000 buckets or so and then the server could decide which section to reply with

Agreed -- I wanted to mention it here so that we at least keep it in mind (mostly for code architecture reasons, I don't think its super important to think...

I would expand this to building the crates in an order such that we'd know ahead of time that crate B doesn't need to be looked at since it's guaranteed...

This would be currently difficult, I imagine, but I think we'd use `cargo metadata` during lockfile generation to discover dependencies, then use that to build up the graph, and use...

Note that currently I believe we need to edit not just Cargo.toml but the root files (lib.rs, main.rs) to insert the preview feature gate. That's likely quite hard to get...

I consider `build-pass` to meant that the crate built (both main and tests, in theory also examples etc. but those I don't think we build today). So I don't actually...

My reasoning is primarily based on the fact that if I know a given PR cannot break runtime behavior, then I can ignore changes in test state, and the reverse...

> Unless we split the two build steps, we miss out on this breakage since we've probably excluded it entirely since the 'build' is always broken. I'm not clear on...

I'd prefer to avoid doing anything special with beta runs as those are fairly critical to Rust's stability guarantees, but otherwise this seems fine.

I don't think the optional dependency problem is actually a problem -- we still test all of crates.io. However, it is true that code changes with various features enabled/disabled so...