You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following up on rust-lang/rust#88832, it seems like a reasonable step may be to restrict bors merges to only happen after any existing perf regressions have been justified.
This might have the negative side-effect of partially discouraging perf runs, but that is hopefully unlikely. Our lack of strong follow up with PR authors + reviewers on perf justification post merge does make it harder to push for it to happen; it may be that some broader T-compiler policy work is necessary here.
The text was updated successfully, but these errors were encountered:
On the social side of things, I think we should push in #t-compiler meetings for reviewers to run perf runs more often. I think the following mantra applies: "when in doubt whether this could cause a perf regression, do a perf run"
I think we've done good work there. We just need to push on the follow up to perf runs. Part of that is likely providing better tooling for diagnosing regressions -- currently it's a bit of an opaque step if the perf.r-l.o UI doesn't show you anything.
Following up on rust-lang/rust#88832, it seems like a reasonable step may be to restrict bors merges to only happen after any existing perf regressions have been justified.
This might have the negative side-effect of partially discouraging perf runs, but that is hopefully unlikely. Our lack of strong follow up with PR authors + reviewers on perf justification post merge does make it harder to push for it to happen; it may be that some broader T-compiler policy work is necessary here.
The text was updated successfully, but these errors were encountered: