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.

svn repos now say "checkout: ssh://..." instead of svn+ssh://, making svn clients are angry.

In T10694#174460, @epriestley wrote:

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?

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?

I'm one of the users whose feedback Peter has been relaying, so let me explain my situation.

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.

In T10939#174449, @epriestley wrote:

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.

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.

In T10939#174447, @epriestley wrote:

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

They wouldn't be added for changes to /a/e/, but they'd be added to everything else, yeah (albeit indirectly, via packages).

We could possibly encode a "if you own a package which owns some parent directory, even if that package excludes the subdirectory, you can 'clear' instead of 'force clear' the block" but maybe we could just use a soft social sort of hint on that? Like when you go to clear the block, it says "you own a parent thing so this is probably OK" instead of "you'd better be sure or you're gonna get fired".

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

We don't care about permissions for force-clearing blocking reviewers at all.

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

In T10939#174442, @epriestley wrote:

I think that already is expressible:

• Package "/": Include /, exclude /a/, exclude /a/b/, exclude /a/d/, exclude /a/e/, owners: aaa
• Package "/a/": Include /a/, exclude /a/b/, exclude /a/d/, exclude /a/e/, owners: aaa, bbb
• Package "/a/b/": Include /a/b/, owners: aaa, bbb, ccc
• Package "/a/d/": Include /a/d/, owners: aaa

In T10939#174438, @epriestley wrote:

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

This probably is also not really covered by the above, and I think some "Clear (some of the?) blocks I am responsible for, but do not actually accept the revision" is perhaps the best way forward.

I think that already is expressible:

In T10939#174439, @epriestley wrote:

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

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

In T10939#174435, @epriestley wrote:

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

This is only a partial fix, but you can exclude /a/b/ from package /a/ if the owners are disjoint (add it as an "exclude" path instead of an "include" path).

This means "/a/b/ is not part of /a/", not "/a/b/ and /a/ are kind of the same except not really", but I think your wrapper script can express this by making all of the /a/ owners also owners of /a/b/, and then excluding /a/b/ from /a/.

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?

general note here: while I've called out a number of specific tasks we (a) don't require the entirety of the tasks to be fixed and (b) we can write a lot of code ourselves thus obviating the need for phabricator fully grok our use case, so long as its emulateable.

This is great, thank you! :-D

Or see @avivey's far more complete response.

We don't support HHVM.

• Neither HHVM nor proxygen are officially supported by Phabricator, see T1261 and https://secure.phabricator.com/book/phabricator/article/installation_guide/ for a list of supported platforms.
• HHVM does appear to support rewrite rules - see https://docs.hhvm.com/hhvm/configuration/INI-settings#server-mode__virtual-host-format, though it might be a little hard to configure.
• You can apply this patch locally, but there's no telling what else will fail to work with HHVM.

Seems to be happening on quite a lot of Wikimedia's phabricator projects: https://phabricator.wikimedia.org/T128160 ... At least I think it's the same bug. I have no idea what might be causing this.

The difference with our interface : I have not installed "http git" only ssh git

The difference with our interface : I have not installed "http git" only ssh git

I cannot change the Space by default

I can't reproduce this. Here are the repository policies:

T10748, which provides the new cluster management UI for repositories, is nearing completion. This makes cluster setup more manageable and at least provides a pathway forward for Almanac stuff in the future, although it does not yet make Almanac / service management explicitly selectable when creating a repository (for now, new repositories allocate on a random open service).

We hit a couple of minor issues (e.g. D15856, D15865) in the last few days, but this seems to be working in production.

We don't appear to be affected directly and I've discussed this in the changelog now, so I'm going to close this out as I think there's no action remaining on our side. Let us know if anyone has questions, etc.

See https://secure.phabricator.com/book/phabricator/article/prototypes/

I ran into this same issue, it was caused by user error, but the error handling of diffusion could still be fixed. Here's how to reproduce:

FWIW I really like proposal #2: