Piledriver was built before the FutureGraph stuff settled in T11968; it runs into the same general set of sequencing problems and yield would likely be a good approach.

I can't figure out how to delete...

I got rid of everything I could, and nothing appears to be affected.

We have a lot of leftover VPC cruft that I'm going to nuke, notably meta and admin VPCs that (as far as I can tell) have nothing in them, and then a bunch of subnets (meta.private-a, meta.private-b, block-public-222, admin.public-a, admin.public-b, meta.public-a, meta.public-b, block-private-3) and some NGWs etc. I'm like 99% sure this stuff is all leftover from testing years ago and nothing depends on it, but I guess we'll see what happens when I delete all of it.

Here's the last known state of the world from T12816:

See also NAT carryover from T12816, via T13542.

Closing this in favor of T13630, which covers the same ground.

I'm planning to simply delete the Discourse forum without preserving any content.

The non-public parts of Phage are currently very specific to Phacility's cluster and probably not generally useful. The current version of PhageRemoteWorkflow is similar to P2107 and depends on particular Phacility services and hosts to enumerate valid remotes and negotiate a connection to them through a bastion pool. These service-listing and bastion-host components are not generalized and not trivially generalizable.

4. As Alice, commandeer a revision authored by Baliey and reviewed by Claire. Edit it locally to do arbitrary bad things, then git push it.
5. Make a commit, edit the commit message to say Differential Revision: D1234, where D1234 is a current, valid, accepted revision authored by anyone, then git push it.

I believe it is extremely difficult to configure Phabricator to provide the assurance you describe, particularly if arc land does anything. If you are actually providing this guarantee ("an attacker needs two machines"), you can likely add a clause to the large amount of custom code you've written to prevent self-foisting while still supporting other foisting use cases. If you haven't written a large amount of custom code, I suspect an attacker can fairly easily deploy with one machine without using "Foist Upon".

See also T12404#256288 for a note on each removal.

each is usually easy to replace and I'm happy to accept a change to replace it if someone wants to reproduce/test it. I believe this (totally ridiculous) construction:

Good catch!

Ah, that's helpful. I found a repro, it's specific to the behavior of the ImmediateFuture pathway for non-clustered resolution of Conduit "calls". This should force it from any configuration/state, I think:

I'll have some more detail in D21717 in a minute, but I can't immediately reproduce this, I think? If I intentionally break diffusion.historyquery like this:

(D21715 is still a draft, but I left a couple of more specific comments there.)

Does this refer to when multiple dependent commits are pushed and then stripped from the on-disk state?

I think this is probably the cleanest fix, but I only tested event imports (which now appear to work). If you want to test Maniphest with subtypes configured (to make sure it doesn't break) and send me a revision with this change, I'll review it. Otherwise, I'll do that testing when I get a chance and land this if nothing crops up.

I found this channel incredibly helpful for repairing/replacing components on boards:

I caught one cosmetic issue in D21711, but this works properly for me locally now. Thanks!

I ran into this while trying to reproduce the issue:

The stalled transactions on this host published after I deployed the update.

(After picking up D21697, the approach works properly in my environment where I originally ran into this, but there are a couple of rebase calls still present in ArcanistMercurialLandEngine that don't use the new API yet.)

This happens when a recipient list includes an Owners package which has been destroyed. Specifically, we'll exit this section of PhabricatorMetaMTAMemberQuery with out the PHID in $package_map, and then fail to return it:

...perhaps we should consider a way to do this automatically or at least less-manually.

• Cryptographically Random Orbit Sander

This ("Queued at") looks suspicious:

In D21685, I've imposed stricter rules for which state transitions are allowed: for example, you can't issue a "pause" command to a build that is already pausing.

There are a bunch of libraries to help with this that I obviously won't be using because I didn't write them...

im a wizard

I think not all versions of Windows + PHP require adjusting php.ini, but some nontrivial subset do -- enough that arc itself emits some flavor of guidance on this:

This is no longer my fight.

For now, this has been working fine as a simple CLI flow.

Ah okay, I'll do some other testing. I was also wondering if there would be cases in Phabricator where something is doing something like if (get_class($a) == 'PhabricatorEnv') {... which if so I'm guessing would cause failures.

One other case where "Phabricator" appears is in HTTP and Email headers, e.g. X-Phabricator-XYZ. For a separate project wanting to update these I think a slow migration approach is needed, to allow recipients currently expecting the existing fields. I'm guessing there isn't a reasonable change here for the upstream.

I should probably just set up a blog or something since I don't expect to bring any microcontroller components upstream, but until then:

Proof-of-concept only for class_alias():

This is a bit out there, but: PHP once had something called classkit and later runkit, which perhaps exists as runkit7 now, that let you dynamically rename classes at runtime. In theory, you could use this as a compatibility layer to support mass renaming of classes: if code asks for PhabricatorXYZ, look for GenericXYZ (or XYZ, or consult a mapping), then make a runtime copy of the class. This narrow capability may be in PHP's core as class_alias(), now.

Create Platform::getProjectRepo() to return "phabricator", or instead detect the repository name.

I think the global flag is reasonable.