@nemobis, I previously warned you about the tone of your interactions with the upstream in T5908#84888.

I don't see how Herald rules are related to the provided "example use case"

Can you update this ticket after reading this wiki please. It will save time for both you and the upstream.

I don't see how Herald rules are related to the provided "example use case" (maybe because it's unclear to me what "MUST acknowledge" actually means). Maniphest's advanced search already allows to combine "Created Before" and "Updated After" to address that "common need" - no Herald needed.

Another example use case: the ability to perform advanced searches based on report history criteria and to send "whines" (as on bugzilla) is needed for any project that wishes to join https://bestpractices.coreinfrastructure.org/ , namely the criteria:

The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix.
The project SHOULD respond to most enhancement requests in the last 2-12 months (inclusive). The project MAY choose not to respond.

On second thoughts, the flexibility of a Herald rule may already be better for me, as I want to filter out Merge Commits from auditing (at least when they are merged by an Owner), since the individual commits that are merged already have their own audit.

Yes, that would also solve the problem for me, and would probably be an easier option for new users.

If the "Audit" setting for packages had three settings instead, would that solve your use case?

We don't officially support localization, though you may use it if you feel adventurous.

In T11112#179360, @eadler wrote:

Not only this, but multiple Herald rules can conflict.

In T11112#179356, @epriestley wrote:

(...) I think these are fairly self-evident (...)

Not only this, but multiple Herald rules can conflict.

We should fix these, but I think these are fairly self-evident and I think fixing them isn't trivial since I recall declining to fix them the last time I was in this code.

If a package is defined with multiple owners (or a group ownership), it is a reasonable expectation that even when an owner commits a change, other owners will review that change. This is how owners has worked up until the T10939 changes recently.

@hach-que Perhaps the terminology isn't really consistent then. When I add a project to an edit, it appears under a heading called "tags". Perhaps the Herald rule should say "tagged with"

@aristedes It means projects and subscribers of the commit. For example, you can add those projects here:

Subscribers -> Are these watchers or members of the project? I don't recognise the word "subscribers" in Phabricator.

It confused at least one person, but I am relatively new to this product.

I don't think the behavior of the fields is unclear and we haven't seen other users run into this particular difficulty.

OK, thanks. Because there is no documentation about what any of these choices mean would you like to make this task a documentation fixing issue?

Code being owned by a package does not tag it with a project.

(Although we do formally support and have documentation for the the "import, then make hosted" and "copy the whole working directory into place" methods of repository import now, both of which skip the pre-receive rules.)

Disabling Herald there only disables the post-push, at-discovery-time rules, not the pre-push pre-receive-commit-hook rules.

Hasn't this been done for a long time? In the current form on the page diffusion/edit/.../page/actions/ ?

I'm going to merge this into T10967. Although it would be possible to fix in advance of that, I think it is unlikely that we'll pursue the changes outside of the larger infrastructure changes discussed there.

I expect that when a package is defined with Auditable enabled, each commit that affect the package will trigger an Audit rule.

I run into this problem a lot because workboards doesn't support custom forms yet :(

Our expectation is to use custom input forms here.

Have you seen the discussion in T8434?

Indeed, it's fixed ! Thanks

This may have been fixed by D15507. Otherwise, we can't reproduce it, so we can't move forward. See Providing Reproduction Steps.

@revi This third party tool no longer exists, the two links are broken and the latest commit at https://github.com/haskell-infra/libphutil-haskell removed the changes:

I've run into this problem with my puppet repositories. A common puppet workflow is to use every branch as a puppet environment.
This way you can test a large change on a subset of production servers before applying it to the production branch itself.

In particular, for anyone hitting this, is your use case anything other than something in the vein of "my users publish temporary/development changes to branches in the remote"? If we implement GitHub and let them dump their garbage into personal forks which are isolated from a Herald perspective, would that resolve the issue?

What about my suggestion regarding evaluating commit newness on a per-herald rule basis, based on which refs would match the herald rule?

We're extremely unlikely to pursue any changes where 99% of the time it works great and 1% of the time a user shows up here wanting to kill us, so arguments in the vein of "it would work for me and other reasonable users who know what they're doing", while likely true, has very weak persuasive power.

A branch or tag can be moved from a very old commit to a new commit, and then re-run rules on a large amount of repository history.

A branch or tag can be moved from a very old commit to a new commit, and then re-run rules on a large amount of repository history.

I don't think you need to do anything new for new refs.

In T6522#173738, @reardencode wrote:

for (commit in commits_between(ref.old_commit, ref.new_commit)) {

How about:

Grmbl. I cannot indeed reproduce it neither with your example, I'll investigate more what's wrong with my (other) setup, that still doesn't work. I'll reopen if/when I find out what's happening. Sorry for the noise.

Per F1256292, presuming resolved until more details surface about what's up.

I can't reproduce this. Here's what I did. I created this Herald rule: