Page MenuHomePhabricator

Unclear distinction between Herald rule and Owners package
Closed, ResolvedPublic


I wanted to make a Herald rule which had the following criteria:

  • Object is a differential revision
  • Repository is any of [some repository]
  • Patches matches regex [some regex]
  • Author is not in #some_project

It occurred to me that I could do this with a Herald rule, but I could also create an Owners package and then change the rule criteria to:

  • Object is a differential revision
  • Repository is any of [some repository]
  • Paths are part of Owners package
  • Author is not in #some_project

Is there any real difference between these two approaches?

Revisions and Commits

Event Timeline

joshuaspence raised the priority of this task from to Needs Triage.
joshuaspence updated the task description. (Show Details)
joshuaspence added projects: Herald, Owners.
joshuaspence added a subscriber: joshuaspence.

I think this relates to T8644, which relates to the discussion starting T7804#107408.

Herald is very powerful, but has a learning curve; For some things that "should" go there, there are extra buttons in places where the user will look for them, but there's an almost infinite number of things that could have this treatment.

IIRC, Owners used to have a checbox for "all changes to this package needs to be approved by the owners", which was more-or-less the same rule you're trying to define; That made the question easy to answer - Owners UI is optimized for managing a list of owners, and is only one checkbox away.

Yeah, they're functionally identical.

If you define a package, it's easier for other users to write similar rules (e.g., several users can easily keep abreast of changes to Aphlict or whatever). It will also be exposed elsewhere (e.g., arc cover after T2443) and you can define audit rules more easily (by clicking a checkbox), see also T1258. And you can search/browse Owners, but can't reasonably search/browse a list of regexps.

Herald generally represents the extreme upper end of the power/flexibility scale, but a lot of things have an easy alternative for common use cases. For example, repositories have an "Allow Dangerous Changes" flag -- which is functionally identical to writing the flag yourself in Herald, but a lot easier to keep track of. Repository push policies are functionally identical to writing push policies in Herald. After T5791, Herald will be able to express all the outbound mail options, but we'll retain (most of) them to provide a simpler UI.

I plan to just improve documentation to address this.