Currently, there is a herald rule (H65) which adds Blessed Reviewers to a diff automatically. This seems like a bit of a hack and it would be great if this concept was built-in to the Repositories application.
This would involve "blessed reviewers" being able to be configured individually for a repository and allowing the herald rule to add the blessed reviewers that are appropriate for that particular repository.
Isn't Herald the correct, and more powerful solution? Is there a workflow here we can fix, do you run lots of repositories and do these operations a lot?
I don't think this is a hack, either. Most of the uses I've seen in the wild (including the ones on this install) are either more granular (trigger on certain files/text) or less granular (trigger across multiple repositories) than the repository level.
The "Owners" tool could theoretically help here, too. Future iterations will probably see it have more behavioral options (i.e., checkboxes you can check which essentially "write a rule" for you), similar to how the "Auditing" option works now. One that has come up in the past is "always CC on changes"; another reasonable one might be "require review".
Most of the uses I've seen in the wild ... are either more granular (trigger on certain files/text)
I can confirm this is definitely the case (using Herald rules to add blocking reviewers for security related changes).
The possibility to make the owners of a repository blessed reviewers of any revision submitted to that repository sounds good. Wouldn't this replicate the Gerrit behavior with maintainers of a repository with +2 (merge) permissions?
I was thinking we could just make jenkins-bot a blocking reviewer, and also set the convention that only jenkins-bot would land patches. Then, jenkins-bot could look at a few factors to decide whether to to approve the patch (which is required since it's blocking):