Okay I was able to run lints properly but running unit tests still failed because I'm not running a proper dev environment yet. I'll definitely get this done before considering this change for landing/submission though.

Still need to nuke the 500 Phabricators

• Move the project and org definitions to PhabricatorPlatformSite methods
• Update existing references to moved place
• Fix the default wordmark so it's not immediately translated via pht()

Just to add clarification around T15009: Evaluate legal organization format ("Foundation"), we can opt to create our own organization instead of joining an existing foundation however that involves a lot more paperwork, submissions, legal stuff, etc. The foundations are a means for speeding along that process, where Apache Foundation, Linux Foundation, etc. create their own non-profit organizational legal entity then "adopt" sub-projects which automatically inherit and become part of their entity as long as we abide by their agreements, largely focused around providing open source projects run by open source communities. In turn they provide benefits like being the actual legal entity that owns the trademarks/copyrights/assets for the project, some even offer to be owner of domain names etc. along with providing some legal assistance for e.g. open source license law or even for initially acquiring trademarks/copyrights.

@jupe yea I figure similar to the Phabricator landing page on https://phacility.com/phabricator/ I think we want a basic static page which showcases the project & features, along with some form of T15010, then points to the other content on this install.

This is my understanding of the items in the description currently, please indicate if this is not correct

I'm redirecting the discussion from D25011 to this task

This is roughly what I was planning on

1. Move PhabricatorApplication::PROJECT_APPLICATION_NAME into PhabricatorSite::getName() (I have a local change for this)
2. Update all existing PhabricatorApplication::PROJECT_APPLICATION_NAME uses to PhabricatorSite::getName() (I haven't yet done this, still figuring out best tooling/environment for PHP development)
3. Update PhabricatorCustomLogoConfigType::getDefaultWordmark() to not use pht() but instead have the callers wrap the result in pht().
4. Grep for Phabricator and Phacility appearing anywhere within single or double quotes. Likely need to exclude celerity-generated files. Replace with PhabricatorSite::getName()
5. Create PhabricatorSite::getProjectOrg() to return Phacility if it's needed from #4

I did skip lint and unit tests for now as I could not get them working properly on my system (something blew up trying to connect to MySQL). I will be setting up a proper development environment at some point.

In D25011#370, @avivey wrote:

@deadalnix: want to move the bigger discussion to a ny task? I'm on a mobile right now.

I am in agreement with @Ekubischta’s comments regarding these functional changes staying on hold until we get the branding and quality procedures in place

I think we should check with the community to find someone using CircleCI who is able to check that this doesn’t break backwards compatibility.

This change looks solid but I am a little concerned about pushing up feature/functional changes prior to getting all the branding work done for T15006: Re-brand Phorge. I haven't been able to spend as much time on that recently as I'd like and would appreciate any assistance on it. I'll update the task to clarify the strategy/approaches that I think we need to address.

This ties into T15009: Evaluate legal organization format ("Foundation") - the majority of foundations for open source will support retaining assets like trademarks/copyrights. It would also be useful if they assist in acquiring them in the first place.

For the development environment this would probably be best in a diviner book/document instead of a wiki.

One thing to consider are installs where the database is being queried outside of Phabricator - anyone doing data analytics or other tooling that interacts with the database directly would be affected by this change. I’m not suggesting we never consider it but it would be better if we can provide tooling/scripts where possible or even create a wider time span for migration. Would MySQL/MariaDB support aliases of some sort? Or maybe there’s a way we can support both namespaces for a time

I created Release Process in our internals wiki to start the documentation on what the release process would look like, based on some of those commented. As we flesh out the plan I’d like to update that.

Abandoning for D25006

Wouldn’t the owners package only cause revisions to be marked, but wouldn’t that leave non-revision commits t not be handled? The herald rules act upon incoming commits rather than ensuring every revision is reviewed.

I updated the herald rules to use O1 so it should work fine next time

Hmm try with this? There are some nuances I think to work out with the herald rule

In D25002#160, @deadalnix wrote:

As an asside, you might want to split up the logo rename part of that diff in another diff, this should be able to get in eight away, and there is no reason to wait on a resolution for the translation business to move on with it.

Still need to search for instances of Phabricator appearing anywhere within quotes. Testing all this will be fun.

• Revert the logo and favicon (but keep logo rename)
• Added PhabricatorApplication::PROJECT_APPLICATION_NAME to default to Phabricator
• Updated instances of 'Phabricator' to use the new constant instead

Updating comment per discussion

Currently rP and rARC only allow Blessed Committers to push - with those herald rules in place should we open that up? Maybe we should have a separate group "Contributors" for anyone who wants to submit revisions for approval? Or should it be opened to any user?

One thing that I think distinguishes these changes from T15006: Re-brand Phorge is that those changes are mostly intended to be submitted upstream in the hopes Phabricator accepts changes which enable more-easily re-branding the project. For Diviner I don't think that's something we can do since I'm guessing all the book content is effectively static.

Oh, excellent! Thanks for looking into that.

Since we're planning to eventually host more-open/accessible community repositories I created these as separate object rules instead of as a global rule

I created H7 Guard Phorge Repo with Blessed Committers and H8 Guard Arcanist Repo with Blessed Committers to guard rP and rARC

It looks like Diviner was used to generate documentation however a lot of the documentation still refers to "Phabricator". We'll probably want a separate task just for reviewing and updating all the documentation to make sure it's appropriate.

@Ekubischta it looks like @chris added you - could you verify your email? I'm also thinking anyone in the "security" or "blessed" groups should turn on MFA as well.

In D25004#131, @tobiaswiese wrote:

I have some concerns regarding the new comment, as these files don't really belong to aphlict, but are npm npm artifcats. If node-ws is installed via e.g. the system package manager (which is probably the better idea anyway), these files/folders won't be created.

I created T15013: Better handling of node/npm installation for Aphlict for further discussion

Yea it probably won’t have an effect until they run npm install/ci. We could create those files and include. I’ll update

I was thinking about having it version controlled and I do think that would be a good idea at some point. If we do that now I think that might mess up installations which happen to be running different versions of ws, or the upgrade path would require some additional steps. I think it would be something like

1. Run npm uninstall
2. Delete package-lock.json
3. Upgrade
4. Run npm ci which should follow the package-lock.json definitions

Update comment

Ah I wasn't aware of that option. I created D25004: Update .gitignore to account for package-lock.json if we want to update the .gitignore

In T15011#386, @Ekubischta wrote:

A few things @willson556

• Untracked file in phorge source support/aphlict/server/package-lock.json

This and D25001: T15006: Update .arcconfig to point to we.phorge.it are duplicates. I tried to land it this morning but ran into issues with the land process that I didn't have time to work out

We should consider a Vagrantfile in place of docker containers. I think it will be more approachable to newcomers having a single VM with all the services/configurations setup compared to managing multiple containers.

I think the plan for this is going to be

1. Try to address all external-facing "Phabricator"s
2. Submit this patch upstream on secure.phabricator.com
3. Phorge pulls in this change from upstream

Renaming getDefaultProjectName() to getDefaultWordmark()

Infrastructure setup is being documented in server

Okay I think everything is setup for the migration to we.phorge.it

• I added a port 80 configuration for we.phorge.it to nginx
• I ran certbot to grab a cert for we.phorge.it, I used --nginx
• I updated the nginx conf file to clean up the automatic modifications and setup secure.phorge.it and secure.phorge.dev to redirect to we.phorge.it
• I updated phabricator.base-uri to use we.phorge.it
• I updated notification.servers to use we.phorge.it
• I restarted nginx

Okay I'm going to try swapping out the URL for we.phorge.it. If everything goes well everyone will need to update their URLs and clone repos. If things don't go well I'll, uh, glue it back together

Notifications are also functional. Took me a minute to remember where the "test notification" feature is located (it's in your user settings > notifications)

Whoops, commented on the wrong task, tested imagemagick in T15006#314

Checking imagemagick

I'm going to get aphlict up and running before looking at changing the domain name stuff. Not having notifications is kind of a bummer.

(I verified by starting a new ssh session over port 2222 and freshly cloning phorge after modifying diffusion.ssh-port)

The ports are switched

• Administrative port is now 2222
• VCS port is now 22