In T15006#849, @avivey wrote:

TBH, I'm a little confused about the way forward here, and I think this our biggest blocker?
I have some time I can put towards this, but I'm not sure what I should be doing.

In T15006#839, @speck wrote:

I think in the case of email headers we would want to duplicate the headers to allow sites migrating time to update their dependence on the existing email headers -- so duplicate the headers to include both X-Phabricator-XYZ and X-Phorge-XYZ, then in a year or so remove X-Phabricator-XYZ. I'm not sure if HTTP headers would be used the same way and might be possible to change those without a migration period.

In T15006#279, @avivey wrote:

• Emails have a bunch of X-Phabricator-* headers, for configuring rules in mail clients.

I don't know how often they are used (GMail doesn't support rules based on headers), but we may want to allow installs to keep it as Phabricator for compatibility.

Added related task T15006 since it could likely serve as a reference for this one... Please undo or stop me if I'm overstepping boundaries

In T15011#370, @willson556 wrote:

I actually started on a VSCode Devcontainer based solution on my GitHub: https://github.com/willson556/phorge-devcontainer

I want to also mention on this topic... Using a pre-packaged VirtualBox image can be a straightforward distribution route, with a drawback being filesize... Perhaps Torrents could be a neat way alternative to distribute something like that, though there would be a few options including sponsored mirrors, etc... VirtualBox is a common Vagrant provider, so oftentimes it is a prerequisite anyway...

We should consider a Vagrantfile

For projects that were tracking upstream previously and able to merge, would this not be a matter of a Git config update to add or swap remotes then merge?