Ah, thanks! That use case makes sense to me too.

Yeah, I think we should end real-time support for the general public.

Use arc call-conduit, not arc install-certificate.

Use --conduit-token.

I think the answer for "A" and "B" is almost certainly that both packages still own the file, and the more specific claim made by "B" does not invalidate the claim made by "A". In particular, "A" can add paths in "B" with 'exclude' rules if the intent is truly for "B" to exclusively own the files.

Finding the "Create Task" button on the Maniphest page is indeed easy on this installation of Phabricator, but it's (at least for me) harder on the WMF one

Specifically, I think I want arc to have this default behavior instead:

It's definitely little uncool, but not needing a binary makes it a bit less relevant.

Broadly, if no explicit base rule is configured telling arc what it should actually do, we try to guess a bunch of "reasonable" things, including the tracked upstream branch if one exists. The word "reasonable" here means "someone filed a feature request asking for it early in the lifecycle of the project before we got strict about not accepting this kind of stuff".

To make arc diff do that, run this command:

Oh, I suppose you pretty much answered that:

huh? wut?

Does that output make sense in explaining what arc diff is doing, or not so much?

I don't want to put badges on handles since I anticipate some badges being awarded by context later (e.g., maybe a "Task Author" badge, or "Ponder Moderator" -- these badges would only show in some contexts). If we do want to do that eventually, handles won't have enough information to know how to build them, since handles don't know which page/object they're loading for.

Can you show me what arc which says?

We should fix the bug where badges don't show for stuff like this, too:

From T8117, I think we can just call this "Packages", and rename the Owners objects (perhaps to "Claims") if there's confusion.

I think we aren't actually going to have a standalone binary for this (i.e., the CLI will just be arc install, etc., with a possible bin/whatever standalone in Phabricator that doesn't need namespacing) so I suppose we can just call it "Packages".

This is T8672. The exact chain of events for the most common case of this is:

Policy settings, or policy settings on the repositories they belong to? Or ghosts.

It sounds like T6004 would obsolete this.

If it was an actual mention, you'd presumably get the mail under the "comment" rule, although it's possible the user in question has also disabled comment mail.

I think this change is correct and the analysis backing it up looks accurate.

In the past, the bulk editor worked like this under a similar theory (and or laziness, I don't remember which contributed more), but we had at least one (and maybe a few? I don't recall offhand) user who failed to guess it and didn't even try the interaction in the bulk editor.

In this case, we should maybe have a way to put a redirect in Diviner, since this atom has legitimately moved here:

I think using FileLock is pretty reasonable. It's a little gross, but I'm not aware of any way to do this synchronization in make itself (although it's possible there is one), and if the process doesn't have write access to the lock it isn't going to be able to run make anyway, so it shouldn't be adding new failure modes.

This behavior is currently expected: this construction means "no effect", not "place up for grabs".

Presuming resolved but yell if you hit anything else. Thanks for the report!

I think that fixes it, let me know? I don't have the local infrastructure to actually test this build step properly yet.

I think that's reasonable, the edit UI is just going to be a bit messy. In some hypothetical world, it would be nice if it were WYSIWYG-ier, maybe.

Awesome, glad to hear it!

Here are some of the reasons we're not just adding a tooltip and calling this done:

I think this use case is reasonable-enough. There's no technical or product reason that the options need to be combined, use cases for separate options were just flimsy/nonexistent the last time this came up IIRC (I think I have an "I'll separate them if anyone has a reasonable use case" comment buried somewhere).

In T7073#132726, @chad wrote:

I think it's a common pattern coming from other software that you need to make an account / login before finding a way to do anything.

@MZMcBride, have you read the article from the documentation that @chad linked earlier?

When I first wanted to report a bug to a project that uses Phabricator, it took me several minutes (!) to figure out how to login

You may want to try running the stable branch instead of master:

Ah, sorry, I was mistaken. Our CloudFront setup is actually more involved than the documentation implies. This host has a simpler setup but uses CloudFlare, not CloudFront; CloudFlare applies weaker SSL certificate validation rules. Here's how we fix the headers before the request runs:

Generally, the expectation is:

Actually, I think the setting I pointed out is unlikely to affect behavior here. I'm not sure how the request is reaching your server with a "Host" header which allows Phabricator to serve the request. Are you forcing this on the server (e.g., overwriting the inbound Host header with the "correct" header)?

Is Behaviors → Edit Behaviors → Forward Headers set to "None (Improves Caching)"?

Specifically, the problematic workflow is this:

This workflow is inherently unsafe, and can not be made safe.

From T9190, this may not actually be specific to the cluster.

I'm going to wait until the Harbormaster doc gets split up a bit before writing details on how to use this, but here's the rough version.

Yeah, there's no way to connect a third-party tool to application-level metrics like queue length right now.

I don't think macros are necessarily a bad idea or anything, and they'd be an OK fix here, they just seem potentially really complicated and involved and like they're only-an-ok-fix for a handful of not-too-important issues.

The primary use case I see for {!bigproject/presentations/pitch.ppt} or {!design/mocks/notifications.pdf} is non-version-controlled resources which are potentially shared between users and updated a lot of times. But basically the same value as Drive or Dropbox: sharing files with familiar filesystem semantics so you can go look in a folder and see stuff with sensible names and non-technical users have a reasonable shot at figuring it out, too.