I think some setting like:

This was moved into the prioritization queue by a particular customer that was interested in defining Owners via Projects via external sync.

Cool -- thanks for the report, and sorry about the issue! Some of the Diffusion/repository stuff has been a little choppy lately as we've rolled out changes in connection with T10922 / T10923. Let us know if you run into anything else.

If your install is not available over http, set security.require-https in Config. This will disable the http URI.

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.

This should now be fixed in HEAD of master -- try updating again? You'll need to git pull in phabricator/ to pick up the change.

This should be fixed shortly by D15876.

The problem is that a user will not read the entire email from top to bottom. There is far too much information to do that on every email that gets sent, and most of it is essentially boiler plate.

I mean that it's minor to implement -- the current plan on T9372 is "don't make any major structural changes, just adjust the existing bucketing algorithm".

I think it's a custom select field with an explicit nonempty "None" value, so display is expected.

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

Awesome! Thanks for doing all the work to figure out what was going on. I'll get a diff out to apply that fix in a slightly nicer way.

This behavior seems reasonable at HEAD and we haven't seen other issues with it.

This report doesn't include reproduction steps so we can't move forward. See Contributing Bug Reports and Providing Reproduction Steps.

It sounds like this is resolved.

Thanks for hunting that down!

I can't reproduce this:

I think there were some bugs in the past that have now been resolved, but I'm not planning to fix the root of this, which is that you can not create repositories if the default "Edit Policy" excludes you, even if you have permission to create them according to "Can Create Repositories".

D15873 makes this explicit in the dialog.

Ah, thanks.

Would putting a large clickable "view thing" button in HTML email like the mock in T6600 potentially help address points (1) and (2) -- something like this?

Overall, I'm leaning toward something in this vein to start with:

Let me look at how much of a mess adding "include, indirect, exclude" modes would be. I do think that's cleaner than pure-social "force clear" for this case if we aren't getting into too much trouble, and it's fine on the application side as long as the parent package is the one weakening its ownership over the children.

I guess we could have a third mode like "exclude, sort of". It's intentional that / owns everything by default so I can't go create a /src/ package and steal ownership of all the important code.

Wouldn't that result in aaa getting added to 100% of reviews in a given repo?

Yeah, I think it got discussed here and there but no one really had a good use case for it.

I think that already is expressible:

Can you walk me though the /a/b/ case in more detail? Maybe I'm misunderstanding.

This would solve other issues with root owners accepting on behalf of everyone accidentally

Another issue that I can't find an existing task for already is that OWNERS are non-hierarchical.

It seems like T8887 would mostly resolve this on its own? That is, you don't need T731, T1279, T10622, if you have T8887, do you?

Or see @avivey's far more complete response.

We don't support HHVM.