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.

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.

A very specific example of my confusion is the decision to place the link to the revision first in the mockup on T10283, and how it contrasts with the stated problem of triage efficiency:

(I think this is broadly similar to the original discussion on T10283, which also framed problems in terms of efficiency but also appeared to enable every inefficient/low-signal option available.)

As a thought experiment, if we sent one email per inline comment like GitHub does (and just repeated the author information several times in the body or something), I think that would technically satisfy all the points you raise:

This feedback is also sort of hard for me to understand.

Is metamta.can-send-as-user not configured in your environment? My expectation is that the mail comes "From" the user writing all the text in the mail, which makes it clear who they are. I expect that this information is normally prominent in the UI of most mail clients.

Haha, alright. You might be able to add it to conf/local/local.json manually as a workaround, but I'm not sure if that'll work or not.

After that action phabricator redirects to the main repo page. Is that expected?

AphrontMySQLDatabaseConnectionBase was renamed but I plan to remove this option anyway.

We iterated on the design a bit and ended up here:

@jcarrillo7, something in that vein will split out of T1460 eventually but we don't have a specific plan for it yet. I don't intend to address it as part of this task.

This is expected, and consistent with git's own definition of "mirror". The exact command we use is:

Inline comments are fixed after D15850.

I think I fixed this in D15847:

D15856 appears to have fixed this

This isn't the most thrilling UI but seems to get the job done. T10912 covers one minor followup issue.

This is getting somewhere functionally; we're going to iterate on the design a bit more internally.

Spacing/padding is definitely pretty iffy in Mail.app, at least.

My early-morning logic went something like "it's still there on disk so...".