Who owns the owners tool?
Mon, Feb 3
Wed, Jan 29
Jan 24 2020
Jan 23 2020
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.
Jan 21 2020
Jan 17 2020
Nov 21 2019
Jun 20 2019
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.
May 3 2019
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.
Mar 13 2018
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?
Mar 8 2018
Mar 7 2018
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
Feb 8 2018
I'm going to roll this forward into T13069, which discusses remaining work for "mail stamps".
Feb 4 2018
Jan 27 2018
Aug 6 2017
seems ok now.
Jul 27 2017
Jul 26 2017
This would be great. For example, in a Xcode project I could create packages for translators/localizers for any path containing *.lproj/
Jun 1 2017
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!