I believe the above changes covered everything, and there hasn't been any more action on the motivating customer issues, although this isn't terribly meaningful.

This is resolved and/or mooted.

I dug up another one of these in PHI1439, but there is a lot of text in that issue that I haven't re-read yet.

A minimal implementation here is probably:

See also PHI1987, which is another motivation for the "diffs with no revision" rule from T12771.

It looks like the case in PHI1977 was actually a situation of attempting to trigger an audit by writing a Differential rule, so the Global/Personal stuff may still be worth fixing but has zero known cases of actual confusion in the wild. I'm less sure how the UI could be clarified around the Audit/Differential issue.

See PHI1977 for a somewhat-similar issue: a user was (probably) looking for an action available only in Global Herald rules, and didn't realize available actions depend on rule scope.

The profiling in D20566 seems satisfactory, and has been useful in resolving or understanding a few performance-related issues.

See https://discourse.phabricator-community.org/t/herald-rule-not-adding-auditors-to-commits-following-upgrade/3505 for one bug with this.

Remaining work:

D20947 does not implement "Author's packages" as a "Commit Content" field, nor as a "Commit Content (Hook)" field. The reason for this is that getting the modern authorPHID in both cases is somewhat complicated.

This should be fixed by D20943. Note that "Mute" in this context mutes notifications about edits to the object (e.g. "Alice renamed rule Hxxx from X to Y."), not notifications sent by the rule itself.

I've moved the issue in PHI1264 (roughly, "commenting on an unpublished commit should still work normally") here from T13284, since it ended up not really fitting into that scope particularly well.

D20808 fixes the two original cases (Harbormaster and Legalpad). There are probably more fields or actions which could be configured to be sometimes-unavailable, but these are probably the major ones.

I understand this was supposed to be mentioned here: Herald ignores commits that are ancestors of permanent refs if they were previously pushed to some other non-permanent ref.

0.00000000001 is very funny and we would be losing a truly great joke at such a young age

A sort of broad issue here is that Herald sometimes knows (or could know, or could guess, or maybe could speculate) that a rule won't do what you expect, but it doesn't tell you.

I think this is about as good as we're going to get, and we've only taken a very small step toward the precipice of a self-aware Herald that hates humankind.

KDE appears to be moving to GitLab (see: https://gitlab.com/gitlab-org/gitlab-ce/issues/53206) and we haven't seen this request from other installs, so I'm just going to close this out.

I think the modern answer here is "use Webhooks". They may not do everything you want if you're writing a chat bot (notably, they intentionally do not currently provide a human-readable text representation of transactions) but there generally suitable for publishing changes to Phabricator objects into a remote system and will produce a program with generally reasonable behaviors and no weird demons lurking under the surface.

Currently, I think the primary transactions and transactions triggered by Herald are getting different group IDs. They should be the same group ID, e.g. all these transactions should be in the same "group" for the purposes of collecting transactions into effect groups:

This stuff is largely resolved, but survived by a few remaining issues in T13290.

pass the applied transactions to Herald

See PHI1107, which requests Auto-Abandon for old changes and also has a technical outline for this great and wholesome feature.

The answer here is now pretty unambiguously "Use Webhooks". feed.http-hooks is formally deprecated, Herald remains a terrible idea, and anyone brave enough to touch Doorkeeper can probably figure things out for themselves.

We don't have any current customer interest in this as far as I'm aware. We could revisit this in the future, but I'd like better / more modern use cases (e.g., that aren't addressed by an approach with Owners).

Although I'm not entirely confident that 100% of objects which should implement ExtendedPolicyInterface actually do today, I think we've gotten pretty much all of them. This approach also seems stable.

I don't believe there are remaining outstanding requests for this.

Owners review and auditing now have 6 and 4 options respectively, which I think cover most of the needs here. They don't handle everything (e.g. excluding merge commits) but think we're mostly in a reasonable place now and don't have any current plans to add additional shorthands.

PHI1159 would like build failures exposed to Herald to trigger audits. See also PHI953. See also PHI901.

In PHI1008, when commit X reverts commit Y, we don't write a revert edge between X and revisions associated with Y. We should.