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?)

I'm no longer able to search for "Responsible Users: (Current Viewer)". Is that expected?

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.

Collecting some additional dashboard cases from stuff merged into T4144:

Packages can now be reviewers. They work very similarly to project reviewers. They can be added via the web UI or Herald. They can also be added via the CLI (by typing O123 as a reviewer or subscriber) but this isn't very convenient and I don't expect users to manually add them very often / ever.

Archived packages are no longer added as auditors to new commits after D15907 by the "Auditing Enabled" setting.

Hi @msatish! Please see Planning for help understanding planning and prioritization. Thanks!

Pretty sure D15918 is the right/expected rule: if you're an owner of "CSS" and "CSS" is set to "Auto Review: Review Changes (Blocking)", it doesn't trigger for your revisions: you don't need someone else who owns CSS to unblock your changes. Let me know if that defies expectations.

This has been slightly streamlined, modern flow is to dump first:

I mostly have T8887 working, but there's currently no way for a package to be rendered unambiguously in Reviewers: ... or Subscribers: ... from the command line in a plain text commit message, so this may be a little more involved than I'd hoped. Everything works fine until you try to interact with a revision that has package relationships, then you get into trouble:

This isn't a bug, the block has a performance-motivated explanation in a TODO comment above it:

T10940 should be resolved now, D15903 should resolve lock granularity.

I'm going to merge this into T9275, which will solve this automatically.

Moving this to "Paused" since we're waiting on feedback / deployment / bug reports / things to catch on fire.

• Patches from metamta.differential.inline-patches should be formatted more nicely in HTML mail at HEAD.
• metamta.differential.unified-comment-context has been removed and we now raise setup guidance about it.
• The View Revision button is functional locally, but waiting on design once @chad gets back from vacation next week, since my version of it looks a lot like I designed it (D15884).
• Swapping HTML mail to become the default is ready (D15885) but waiting on the button and maybe a few other designey tweaks we want to consider.
• There's an hour or so of time across all of that which I haven't tabulated yet, but I'll settle it up once those changes actually land.