arc diff is not expected to upload coverage information without additional configuration.

You're also two months out of date, see Contributing Bug Reports.

Please include reproduction steps when filing a bug report. See Providing Reproduction Steps for help.

Blocking reviewers can now be added, edited and removed via the web UI with the blocking(...) function. For example, entering blocking(epriestley) into the "Reviewers" typeahead will add epriestley as a blocking reviewer. You can use this to upgrade reviewers to blocking or downgrade blocking reviewers to non-blocking.

I've consolidated the general state of the world in Audit in T10978. I think we'll run into some of that eventually but I'm not sure how much is important vs nice-to-have, so my general plan here is to just scratch the surface for now:

See T3498.

When we can identify the author, I'm just going to make auditing stop trigger audits by any packages they own, even if there was no review.

Presuming this was fixed some time in the last four years, barring any new reports. The code has code to do this, at a minimum.

I think this was effectively resolved by T8004 / D13923.

At HEAD (after D15929), bucketing is now more considerate of individual reviewer status and cases in T5217 should be handled in line with user expectation.

I'm going to merge this into T10967. Although it would be possible to fix in advance of that, I think it is unlikely that we'll pursue the changes outside of the larger infrastructure changes discussed there.

When you deleted the user, did you see this prompt?

At HEAD, I can't reproduce this:

I think this is covered by T8612, unless you can produce a small change which requires a disproportionately large amount of time to render. It is expected that large changes will take a proportionately large amount of time to render.

No clue how to reproduce this and haven't seen anything similar in the ~year since. File a new one if you have some idea how to repro it.

But a root owner's accept will still count for the sub-package, provided dominion is weak?

The driving use case for this fell through, and I no longer plan to pursue it.

Ah, thanks for following up. That's interesting and a little perplexing, although just fixing this stuff via T10967 is probably still the best way forward. I'll keep an eye out for similar reports, though. That does tend to make me think it might be a real race.

I'm going to merge this into T10967, since after digging around in the code a bit recently it seems unlikely that we'll pursue the infrastructure changes required to fix this outside of the context of that larger infrastructure change.

I expect that when a package is defined with Auditable enabled, each commit that affect the package will trigger an Audit rule.

(I'll restore viewer(), it's just not a one line change.)

Just to make sure I'm understanding correctly:

I can only reproduce this if (3) is changing "Visible To", exactly: i.e., same file policy scrambling issue as T10778. Should have the same fix.

Likely the same as T6815 since I think they're the same code.

The default home page (and homepage sidebar notification count) are also still doing the old grouping / counts. We should probably fix that but it's not a strict dependency here and there's adjacent work (T3583).

Yes, since it would really mean exact(current-viewer) without additional work. Are you using it for something (dashboards?)

Bucketing is now controlled by a "Bucket: ..." option in the search query controls instead of hardcoded as a behavior of the "Active Revisions" filter. This means that you can apply bucketing to other queries. You can also extend DifferentialRevisionResultBucket to implement your own bucketing algorithms (but: here be dragons).

I'm going to merge this into T10939, which answers this question in practice if not in theory.

There are now six buckets which are more action oriented (Must Review, Ready to Review, Ready to Land, Ready to Update, Waiting on Review, Waiting on Authors) and bucketing is more flexible.

In T9263#175460, @epriestley wrote:

(The slightly more intuitive "Reviewers: SomeProjectName" will also work.)

D15930 adds an icon hint for this that looks like this:

(You can create an oldest-first dashboard yourself now if you prefer the old ordering, and can probably force it on all users after T4103 if you really want.)

This also indirectly flipped the ordering from oldest-first to newest-first. I'm inclined to retain that ordering, since it's consistent with every other application. The "oldest-first" ordering was a sort of paternalistic attempt to force users to review stuff, but I think we've generally moved the software away from that a bit and it doesn't feel very much at home to me any more.

I pushed that stuff live but bucketing has some bugs, looking into it.

(The slightly more intuitive "Reviewers: SomeProjectName" will also work.)

I have marked D15925 as fixing this. T10939 has some broader discussion. This isn't an exact fix for the original request, but I suspect it may be close enough to be satisfactory.