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 was effectively resolved in 2019 Week 17 (Very Late April). Now, only ancestors of "Permanent Refs" trigger any publishing behavior (audits, notifications, feed, etc).

This is very old and it doesn't look like we ever found a working set of reproduction steps.

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.

Yeah, that was the commit that reminded me how I wanted this. Unfortunately, it looks like the database still stores literal repositoryPHIDs, so the schema would need to change if it were to handle functions (which is why I bumped the ticket instead of taking a stab at implementing it myself first). I figured I'd add my voice to the ticket for now and continue toiling along with complex Herald rules for now.

After D19191 it would be relatively easy to support projects and wildcard functions (like "Any Repository") but there's currently no interest in this from customers.

I don't suppose there's been any interest in adding wildcards/function matchers to Owners in the last couple of years?

I believe the behavior of this UI should generally align well with what reasonable users might expect, now. In particular, /src/backend and /src/backend/ are now exactly the same in terms of actually resolving ownership, although the UI will continue to show you the value you entered (to avoid confusion where someone types /docs/README.md and the UI echoes back /docs/README.md/ and they have a reasonable concern that the path wasn't understood).

Probably better is to add pathIndex

I'm going to roll this forward into T13069, which discusses remaining work for "mail stamps".

seems ok now.

This would be great. For example, in a Xcode project I could create packages for translators/localizers for any path containing *.lproj/

It's possible that didn't get everything, but yell if you hit anything else and we can shovel on some more test cases. Thanks for the report!

@epriestley yes, the tested owner packages were both weak dominion. Sorry for not mentioning that earlier. You've explained the issue perfectly as far as I can tell. The changes you have planned make a lot more sense than the current behavior and should fix the issues we were seeing. Thank you!

@lvital, I can only reproduce this if use "Weak Dominion". Is that the case in your example, too?

That could work too. Perhaps a box of donuts instead though.

Another approach might be to do T11934 first, and then implement this as /accept-magnainmously. This would be very hard to discover, but it's possible that ~10 users worldwide are meaningfully impacted and I could send them each a nice fruit basket with a card explaining the feature.

In T12758#225035, @epriestley wrote:

Another solution I could imagine is to add a distinct action, other than "Accept", which works like the old "Accept" did, i.e. "Accept for all reviewers I have authority to accept for", say "Accept Magnanimously".

I'm hesitant to pursue this today because I want to be cautious about adding too many actions, and I think other changes may add more valuable actions ("Accept Next Update", draft-state actions from T2543, etc). This action would probably be fine today in isolation since the dropdown doesn't feel too cluttered right now, but if we added it I think it might be the least valuable / least frequently used action in a list that is starting to look pretty bloated six months from now.

(I think it's also somewhat hard to pick a 2-3 word phrase which clearly describes how this potential action differs from "Accept" -- I can't come up with anything good offhand.)

Another solution I could imagine is to add a distinct action, other than "Accept", which works like the old "Accept" did, i.e. "Accept for all reviewers I have authority to accept for", say "Accept Magnanimously".

FWIW, a check-all box is what we had in mind.

A vaguely related issue is that the "Paths" list is not sorted on the "View" UI:

oh dear, what did I get myself into.