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

(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.

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.

In T10939#175260, @epriestley wrote:

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 is being worked on in conjunction with T10939

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.

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:

(I'm just getting this into the preflight column for communication purposes since there's a slot reserved, we won't start work on this until we have an explicit confirmation.)

Yeah, that setting is exactly what I'm getting thanks. Thanks for the info.

I think some setting like:

This isn't required for our workflow but something that would simplify the implementation for us.

I mean that it's minor to implement -- the current plan on T9372 is "don't make any major structural changes, just adjust the existing bucketing algorithm".

Reading through this discussion, it seems like we've gotten to a point where we have a reasonable simple yet general mechanism that allows us to express what we want in terms of the owners themselves.

For completeness, OWNERS are very briefly discussed in T8426.

Overall, I'm leaning toward something in this vein to start with:

I also may just restore this at some point to align with user expectation, even though I think it's a bad feature and we benefited on the balance from removing it.

It has been asked in Q287 too.

I think you should be good to go at HEAD now, let me know if I missed anything.

We ran into a case where archived packages were trigger builds, which didn't feel right and was causing problkems. I'm not sure what the default behavior loadAffectedPackages should be or what would be most consistent with how archiving is handled elsewhere.