FWIW this exact set of reproduction steps no longer works. However, an Owners package set to generate an audit, but without any members, will be unclosable as well.

I don't want to continue expanding the existing "mail tags" system in Settings → Email Preferences. See some discussion in T11337.

In T10939#176633, @Luke081515.2 wrote:

General question: Why is the owners option "Add as reviewer (blocking)" if an owner uploads a revision? I know that this is expected, but why? For example at Wikimedia we currently have the system, that every change needs a review from an "owner" before the patch gets merged, so it's not useful, if an owner of the package uploads a change, and no reviewers get added. Maybe the a compromise may be a setting, where you can choose, if a package gets added as reviewer too, if the author of the revision is an owner too? I think that would help all.

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?

As an alternative to Luke081515.2's request for an option, I just filed T11118. This would also allow an easy return to the old behaviour of always triggering audits, regardless of who the author is.

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

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.

We have a somewhat-legitimate technical reason for this behavior: when we compute which-packages-own(list-of-paths), we do so by splitting the paths into components and then querying for the components. a/b/ is the best database representation for this.

This was a legitimate upstream bug and I was able to reproduce it by following your steps, thanks for the report. D15971 should resolve it.

I just looked the description in 74e117ae41dd.

In T11012#176923, @chad wrote:

We require reproduction steps on all bug reports, this way we know we're fixing your actual bug, and have a means to test and verify any fix. As Owners was recently overhauled with many new features, it's hard to identify what case we may have missed in testing.

I understand that. Will try to find reproduce steps.

I have not found a concrete way to reproduce it. Sometimes the status is correct and sometimes it's not and I can not find any difference on those commits yet.

In T11012#176731, @chad wrote:

This may also be T11015.

In T11012#176668, @chad wrote:

Please follow all the steps in Contributing Bug Reports. Specifically we need to know how to reproduce the issue locally.

@joshuaspence, see T11010, I think. Not sure why nginx was 502'ing there, but should be fixed in HEAD.

This may also be T11015.

I suspect it isn't going to get very far because we lose our ability to optimize lookups (I wrote this in the general case as "regexp", but mean "regexp/wildcard" -- wildcards aren't as complex but I think the general case still holds).

Please follow all the steps in Contributing Bug Reports. Specifically we need to know how to reproduce the issue locally.

General question: Why is the owners option "Add as reviewer (blocking)" if an owner uploads a revision? I know that this is expected, but why? For example at Wikimedia we currently have the system, that every change needs a review from an "owner" before the patch gets merged, so it's not useful, if an owner of the package uploads a change, and no reviewers get added. Maybe the a compromise may be a setting, where you can choose, if a package gets added as reviewer too, if the author of the revision is an owner too? I think that would help all.

I don't know how to reproduce the issue, but figured I'd let you know that I'm seeing this in our error logs:

That cleanup stuff should be cleaned up now, so I'm formally pausing this for feedback.

In T10939#176076, @eadler wrote:

I'm referring to the home page dashboard.

By this I mean: as installed on the FreeBSD install.

Ah! Okay, cool. Not really PEBCAK, I need to fix that dashboard too and it's super confusing that it does something weird/different with no clues about it. I just wanted to see if anyone caught major issues with the new one before swapping it.

I'm referring to the home page dashboard. I just made some config changes (particularly, changing the limit of the number of revisions to show) and it seems to have 'fixed it' so the problem above would be PEBKAC :/

The default is still

That's not expected, but I can't immediately reproduce it. Here's my local install, note that D4 appears in "Ready to Review" even though I (admin) am only a reviewer via project membership in Stonework (a project):

#twitter hat off. FreeBSD hat on.

Blocking reviewers can now be added, edited and removed via the web UI with the blocking(...) function. For example, entering blocking(epriestley) into the "Reviewers" typeahead will add epriestley as a blocking reviewer. You can use this to upgrade reviewers to blocking or downgrade blocking reviewers to non-blocking.

Sounds good (including your last comment). I think that from our perspective, we're it seems likely that we'll end up realizing a few problematic edge cases or details once we start integrating fully and it's probably best to wait until then than to try to gain perfect confidence ahead of time. The work done so far and what you outline in your last comment seems sufficient to start doing the integration work and we can surface issues as they arise.

I've consolidated the general state of the world in Audit in T10978. I think we'll run into some of that eventually but I'm not sure how much is important vs nice-to-have, so my general plan here is to just scratch the surface for now:

When we can identify the author, I'm just going to make auditing stop trigger audits by any packages they own, even if there was no review.

right now, out workaround is to use herald to create the audio, and use "author is not any of " the single person group. a better explaination of the situation was written in my T6701.

Presuming this was fixed some time in the last four years, barring any new reports. The code has code to do this, at a minimum.

But a root owner's accept will still count for the sub-package, provided dominion is weak?

In T10939#175619, @epriestley wrote:

Just to make sure I'm understanding correctly:

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

(I'll restore viewer(), it's just not a one line change.)

In T10939#175557, @epriestley wrote:

Yes, since it would really mean exact(current-viewer) without additional work. Are you using it for something (dashboards?)

Just to make sure I'm understanding correctly:

In T10939#175518, @epriestley wrote:

• "Soft Accept" / "Unblock" action ("TBR").