I've created a task upstream to start the discussion about how to rebrand
https://secure.phabricator.com/T13658

Note that epriestley has provided valuable insight and even looked at making some updates
https://secure.phabricator.com/T13658
https://secure.phabricator.com/D21678

He's made several great suggestions. To level-set on expectations these rebranding changes are likely going to take a fair amount of effort, which with my own availability and (lack of) PHP developer effectiveness may take a while to get through. I think these are the options we have:

1. Cooperate with upstream to develop changes they would accept. Once they're accepted/landed upstream _then_ fork the project, land a change with a rebrand, and land all our existing customizations/changes.
2. Continue forward with the approach in D25002.

I would prefer option 1 as I think option 2 results in a large initial divergence from the upstream in core/essential/foundational parts of the project.

I think despite either option we can also figure out how to better parallelize the work. I think how we manage that will differ based on which option we move forward with however.

What are everyone else's thoughts?

If the up stream is willing to accept any patches related to rebranding I think getting that implemented and then creating the fork would be ideal and then we can start continuing to update the code base here while other people that clone it can just rebrand for their businesses or use cases or whatnot (or additional forks)

This may end up taking more time but I think this makes the most sense in regards to just making the software more open and versatile

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.

Maybe this is at least sort of public-facing branding to where it should be or have to be changed...

On the topic of this whole thread.... what if we come up with a standard highly-greppable name to get the ball rolling... The idea is that if it needs to change or become configurable, it's easy to find very specifically...

Example: Phorid (Short for "Phorge Identifier")..

"Forid" doesn't seem to have an English definition, though "Florid" (Phlorid) does...

So the headers would become X-Phorid-* .. Seems worth having a config variable for this, so that's one way to use a placeholder such as Phorid.. to use it anywhere that will eventually (or rather quickly) be swapped with a configuration variable (which would then of course be set to Phorge)....

Example here: https://we.phorge.it/source/phorge/browse/master/src/applications/metamta/engine/PhabricatorMailEmailEngine.php$379

$headers[] = $this->newEmailHeader('X-Phabricator-Must-Encrypt', 'Yes');

Becomes:

$headers[] = $this->newEmailHeader('X-Phorid-Must-Encrypt', 'Yes');

For initial migration, then later becomes something like:

$headers[] = $this->newEmailHeader('X-' . PhabricatorEnv::getEnvConfig('core.instance-indentifier') . '-Must-Encrypt', 'Yes');

Another reason I'm suggesting this is because I really want to jump in and check some of these boxes, and it would help warm up cold feet to know that these variables would be easily findable in the code...

There could even be a subdomain alias for this specific purpose: https://phorid.phorge.it/ (though the migration subdomain could be something else greppable like https://to.phorge.it/)

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#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.

Good plan... so in that case it would be useful to have a deprecation notice before the X-Phabricator-.... lines.

There is this: https://docs.phpdoc.org/guide/references/phpdoc/tags/deprecated.html

Not that the whole thing should use PHPDoc scattered around, but it would be an option for a standard greppable deprecation notice that would also be parse-able by some IDEs..

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#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.

What I understand is that public-facing branding has to be updated, and also some directory structures and URLs... The main directory has changed from phabricator to phorge

Email headers may be a special case, where a transition is introduced -- so in that case there are two headers sent, and the one that references Phabricator is deprecated with a plan to remove it after some time...

But something like this: phutil_get_library_root('phabricator')

Would become: phutil_get_library_root('phorge')

I suppose that even though it could be an opportunity to set a stage to make it configurable doesn't mean it has to be or even should be...

Actually here is where that particular library is registered: https://we.phorge.it/source/phorge/browse/master/src/__phutil_library_init__.php$3

So changing that to phutil_register_library('phorge', __FILE__);

Should in theory allow calls to phutil_get_library_root('phorge') to return the right path...

There's a lot of work to be done here. I've been coordinating with upstream to find a solution, though EvanP has indicated that we should probably take a few swings at solutions to see what does or doesn't work out. I've been out for the past week on holiday so I haven't made any recent progress.

This is the path that I'm going to be working on

1. Coordinate with upstream to create a revision that easily enables rebranding of the project
   • So far EvanP has made some changes (though not yet landed) which remove most uses of "Phacility" as well as his username from the application, and also remove other miscellaneous things like the ubuntu/centos installation scripts (which use "Phacility" and "Phabricator").
2. Create a new fork of Phabricator to start Phorge from, based on these rebranding upstream changes
3. First diverging commit to be re-brand as "Phorge"
4. Re-apply our current landed changes

For #1 the strategy is going to be

1. Create a handful of static functions to getPlatformName() = Phabricator, getProjectRepo() = phabricator
2. Make updates to appearances of "Phabricator" in the interface to prefer, in order:
   1. Removing the name if it's not needed in context
   2. Replacing the name with a generic reference (e.g. "the platform")
   3. Replacing the name with getPlatformName()
3. Make updates to uses of phabricator as a path to use getProjectRepo(), including phutil_get_library_root()
4. Add a ReMarkup parser that can swap out something like ${{{ platform.name }}} to use getPlatformName()
5. Update diviner documents to use this new remarkup block to allow easily re-branding the documentation
   • Note however that document titles do not use remarkup for rendering, so a different solution will be needed for where "Phabricator" appears in diviner document names.
6. Update code which produces links to diviner documents based on the document name to do a similar platform-name swap out
7. Create new diviner documents based on user-exposed references to Tnnnn or phurl.io, based on the relevant content hosted on secure.phabricator.com
8. Updated references to Tnnnn or phurl.io links to instead link to the new diviner documents
9. Leave HTTP headers and Email headers alone for now. I'm not sure there's anything reasonable that can be done for these (it might be possible to update HTTP headers without any regressions though I'm not familiar enough with what they're used for).

Additionally EvanP provided a proof-of-concept which would allow for mass-renaming files to strip out "Phabricator" but still allow classes defined as PhabricatorXYZ to be loaded by PHP. This works through some reflection hackery and would require us to build a mapping of old classname -> new classname. This would allow us to more confidently rename classes, as any used via reflection would still load properly even if using the old class name.

This is what I currently have planned. I'll update the task description with this information.

Also note,

In https://secure.phabricator.com/T13658#255994 , @epriestley wrote:

Given the amount of work involved here, I would perhaps maybe suggest you identify and implement, like, 3-5 useful patches which aren't upstreamable before moving forward with this, just to make sure you don't end up sinking a ton of hours into something that's sort of moot. (But maybe there's already a clear case for doing this legwork.)

@speck What can I help with here? - Are we waiting on upstream for anything currently?

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

I think I’ve worked with upstream to understand what changes they would likely accept and it’s a matter of getting things organized and segmented into reviewable pieces.

Additionally for testing I haven’t spent any time getting a Phabricator environment working on my main personal development machine which is a windows box. That’s been a personal hurdle in terms of gaining momentum.

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

Yes - I could have some availability - Normally evenings (US Central Time) -

I think I’ve worked with upstream to understand what changes they would likely accept and it’s a matter of getting things organized and segmented into reviewable pieces.

Additionally for testing I haven’t spent any time getting a Phabricator environment working on my main personal development machine which is a windows box. That’s been a personal hurdle in terms of gaining momentum.

If you have docker for windows and vscode, this setup is a cinch - https://github.com/willson556/phorge-devcontainer

Also this Vagrant pattern should work first-run with vagrant up: https://we.phorge.it/T15027#852

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

I'd like to join, but I'm but my availability is wacky due to being in a strange timezone. I'll try to work with what you can find.

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

I'm interested in joining the meeting

As part of {E1} we reviewed this as a priority item, and have created T15077: Rebrand: Tracking task for concrete first steps forwards. There is a lot of text to update and review and that task is setup with instructions on how we're approaching it as well as listing out all the individual applications to update. Anyone interested in assisting please review that task and feel free to put your name on an application/folder, as well as ask any questions for clarification.

We should also change the internal name to the future name of Phorge, rather than leaving leftovers. Exmaple: Some code in Fandom is still named wikia.

i can see a few mentions of Phabricator on the documentation, i am not sure if its because the documentation was left out, or because there are some elments in the codebase that still mention phabricator.

PHABRICATOR_ENV

mentioned here: https://we.phorge.it/book/phorge/article/advanced_configuration/

I changed everything branded Phabricator in th 10k files in my fork to Phorge and applied this change to filenames.

Noticed a few dangling phacility references in URLs in documentation, which could lead users to grabbing upstream Phabricator versions by mistake:

phorge/src/docs/user/field/xhprof.diviner:  $ git clone https://github.com/phacility/xhprof.git
phorge/src/docs/user/userguide/arcanist.diviner:  some_install_path/ $ git clone https://github.com/phacility/arcanist.git
phorge/src/docs/user/userguide/arcanist_quick_start.diviner:  somewhere/ $ git clone https://github.com/phacility/arcanist.git

corresponding to:
https://we.phorge.it/book/phorge/article/xhprof/#installing-xhprof
https://we.phorge.it/book/phorge/article/arcanist/#installing-arcanist
https://we.phorge.it/book/phorge/article/arcanist_quick_start/#installing-arcanist

and, from a quick grep -iFR "phacility" in the root of Phorge:

• the application field in the JIRA API in Doorkeeper: phorge/src/applications/doorkeeper/worker/DoorkeeperJIRAFeedWorker.php
• the ICS PRODID in phorge/src/applications/calendar/parser/ics/PhutilICSWriter.php might need to be updated.

Under Arcanist, arcanist/src/docs/article/overview.diviner:

libphutil is developed and maintained by
[[ http://www.phacility.com/ | Phacility ]]. Some of the code in this library
was originally developed at Facebook, and parts of it appear in the core
libraries for <http://www.facebook.com/>.