I think I've pushed this approximately as far as I plan to in this iteration. Everything mentioned in the description has been tackled, and audits on this install are now in a relatively sane state.

Ah I guess it was a custom query - I checked someone else's dashboard who I know shows audits and theirs did not have the same issue as it was using a built-in one. Thanks for explaining, I can see how migrating a saved query would be difficult/impossible with no major benefits. I had never come across that type of error showing on page like that before and just wanted to check.

🐕

is that expected for this?

I upgraded to 5efbf4d74aa72c5a7d7f161ea8c5aa33ac0e3189, after which when navigating to the list of audits on dashboard I get an error:

Exception: Query "need" is unknown to application search engine "PhabricatorCommitSearchEngine"!

The dashboard panel used the "Needs Audit" query (I believe was at least based on a default query) - is that expected for this? After modifying the dashboard to use a new panel using the new "Active Audits" query the dashboard correctly shows the results.

After D17252, audits now have a "Request Verification" action and a "Needs Verification" state. These states prompt auditors to verify the remedies the author has offered have addressed their concerns. Intended usage is along these lines:

I'm going to merge this into T2393, where I'll discuss this shortly.

In https://github.com/aik099/phabricator/commits/jenkins-integration branch I've:

This report is probably correct and the remedy is likely also correct, but getting lint into Diffusion is completely in shambles so I'm actually not immediately sure how to reproduce it, at least in a reasonable / moderately-convenient way.

I think the big trick on this is going to be making inline comments work somewhat-correctly in the extreme case of octopus merges.

This also seems a little hard to believe to me, at least in terms of being a general flaw with this workflow:

the auditor may spend a significant amount of time before even realizing they've already looked at the changes.

You're not wrong ;). I'm mostly referring here to a scenario where a significant enough time has passed where the auditor might not remember the individual commits (months), so the list of merged commits doesn't provide too much value. The user then would have to click on each one to see if they reviewed them already, and then still try to figure out if htere are any additional changes.

The proposed heuristic (different author and committer) feels pretty shaky, since if you rebase some of your own commits they'll have the same author and committer. I would guess this is somewhat-common in mis-rebases from master?

My merge of T6557 here was questionable, but I think this is a case where the audits are basically correct and the remedy is better cleanup tools.

Sounds good, thanks.

On re-reading T3917 I agree it has approximately nothing to do with this, but see also T5338, where I think I go through a flow like this and it doesn't trigger an audit.

It seems like T3917 is asking for content similarity search (or something similar) as you mention, although falls short of automatic exclusion rules. I don't think this case is covered by T3917, but I'll file another bug, which hopefully will be more descriptive, and I'll let you be the judge of that.

Per above, not sure how to reproduce this.

I don't believe this report, but here goes:

I'm having some difficulty figuring out exactly what this and related reports are describing.

I'm not sure that's the same issue. Broadly, T3917 seems to describe a situation where multiple commits with the same content have different identity due to rebases or cherry-picks. This situation has to do with the exact same commit being re-audited due to merge. I guess it technically possible to review individual commits, then merge them into another branch while also making additional changes, but I would guess that's generally not the case and there doesn't seem to be a lot of use in re-auditing all the changes that have been audited individually, but now as a whole. So in a nutshell what t his is asking for is to only trigger an (automatic) audit on merge commits if:

• audit doesn't exist for all commits being merged
• there is a non-empty diff between the top of the merged branch and the top of the merge destination. I.e. there are additional changes made during the merge.

I'm going to merge this into T3917, which I think is the broadest description of this issue.

D17221 adds an "Auditors" field to Herald.

Thanks, D17218 should fix this.

I'm going to close this since the original use case seems to have not panned out. We're still open to building this, but would like to see a modern use case driving it -- feel free to file a new request (or leave a comment here) if you have one.

I'm going to switch this view to show overall commit audit status, not weird semi-viewer audit status. At one point it wasn't clear how heavily we were going to try to skew views to account for viewer status, but bucketing changes seem to have reduced the need for this and I think extending the Differential model to Audit now makes sense. See also T9430 for some context.

I'm going to merge this into T7076, which discusses revisions instead of commits/audits, but the resolution for both is likely the same and that task has a more complete discussion of context.

I believe this is probably obsoleted by D17192, or will be obsoleted by T2393.

After D17192, all commit states can be queried explicitly:

After D17192, audits bucket into a dashboard like Differential. Feedback from the Differential bucketing changes has generally been positive, so I think this is probably generally a good direction. It also improves consistency between the applications, if nothing else.

I've marked D17192 as resolving this because viewer() now means "viewer, their projects, and their packages", like Differential. exact(<user>) can be used for exactly a specific user.

We could resolve this by implementing "Responsible Users", like Differential.

I'm going to merge this into T9430 since they have the same upstream remedy. This query has largely been modern for some time, but I want to sort out T9430 before providing diffusion.commit.search.

Yep @epriestley this one looks fixed.