I want to work on this eventually but I haven't had the time.

This error handling block is incorrect:

The general plan here is to switch unit test configuration to an .arcunit file by default (T5568). This technically works today but isn't quite ready for use yet.

Yeah, there's no separation of Join/View policies currently.

It is done.

Presuming resolved since D13931 is in HEAD. Thanks for the report!

D13939 will fix T8672, the most immediate cause of high log volumes, but I'm going to hold it until after we cut the release since it also raises the urgency of potential existing errors.

See T9213 for another case of htis.

I folded this into D13939, which also fixes the root problem (hopefully). It ended up with a LiskDAO change so I want to wait until after we cut the stable branch on Saturday morning.

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