Mark Rousskov

> At this point the experiment has been in the generating report state for almost 17 hours, that's a significant amount of time of a fresh check run. Yeah, that...

The goal is precisely that you can quickly grab the full set of logs (at least for regressed crates, but ideally all crates) for local analysis. The tarballs aren't super...

In some sense, if we had a relatively fast UI that served content *from* the tarballs, I'd rather drop the individual files stored in S3 -- those are (more) expensive...

> Running manually is always an option, and running it automatically only on rustdoc PRs seem reasonable. With the upcoming runtime benchmarks, we will maybe also need some semi-automatic way...

Perhaps a debug-assertion and/or eprintln that warns if we see repeated reads of under (say) 4kb on a File? If we had some notion of metrics or other "debugging opt-in"...

cc @BoxyUwU @bors r+ rollup=never p=5

@rfcbot concern side-conversations I would like to see the quote @eholk mentions added/referenced, at minimum. The current language: > encouraged to do so if they have important context to add...

r=me if this is still ready to go (not sure if other changes have landed in the last month that make a rebase make sense). I think we can land...

> C++ `fstream::close` reports errors by setting an internal file operation error bit. This may throw an exception if the file stream is configured to throw on internal file operation...

> At the moment the FIPS defaults reflect local knowledge of what algorithms are FIPS-approved or FIPS-pending It seems like in FIPS mode, it may make sense (given limited adoption...