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

@chris I'm looking to make the SSH configuration change shortly, having the administrative ssh go over port 2222 and vcs go over port 222. In the event everything goes horribly wrong does someone have physical access to this machine or some other control mechanism?

For the time being I've modified the wordmark configuration to manually upload the logo file https://secure.phorge.it/config/edit/ui.logo/

@avivey the current installation includes a commit I had made on the github fork which made minimal changes to rebranding. Ultimately I think we'll want to scrap that commit but it should have replaced the eye icon with a lovely heart.

• move administrative SSH to port 2222

This one is going to require that everyone who currently has a cloned repo to update it, correct? I'll take a look later tonight at swapping this out, as the sooner the better IMO. I'll comment here before making the change.

I created Release Process for the release process.

In T15000#289, @avivey wrote:

https://secure.phabricator.com/book/phabricator/article/diffusion_hosting/

I think /var/repo should be owned by git:

The user the daemons run as. We'll call this daemon-user. This user is the only user which will interact with the repositories directly. Other accounts will sudo to this account in order to perform repository operations.

Do we have a documented release strategy? I'm not very familiar with git and I only have a vague sense of what Phabricator's release process was. I think it's something like

• Accepted changes are landed into master
• Evan cherry-picks changes from master into stable to "release"

Possibly with some additional smoke-testing somewhere in all this?

I think there might be some permissions issues with the log location but I'm not sure if it's the root cause of the issue being seen here.

Just copying my thoughts I wrote from the zulip

IMO our landing page needs to have a summary of our vision statement or something similar that explains what this is and where it’s going, along with screenshots and links to documentation on how to install/configure.

Personally I would prefer having a separate landing page that is primarily static content as I do believe it lends to easier intro of a product (along with some credibility) - however those things are primarily to increase adoption which is not one of our current goals as well it does add overhead and isn’t critical - I wouldn’t mind holding off on that for a while. Phacility’s main website was effectively the landing page for Phabricator. I don’t think it’s still around for reference but it had most of what I described.

I do think we should consider a separate landing page as prerequisite to announcing the product on other websites. Maybe it’s not a strong enough argument but if we’re announcing in other sites then we are probably trying to increase adoption or build the community.

I don’t think it has really started yet. I had some changes on GitHub which I’ve abandoned but I think those changes were copied into the install here.

When changes are made please document what all they end up being.

From my notes

On the topic of increasing community involvement we will also want to produce documentation for setting up development environments as well as the steps to submit changes upstream (like a quality checklist). To make development environments even easier we might want to consider supporting something like a vagrantfile so people can get started with very few steps.