Thank you @cark, I reached out to James Daniel.

Thanks for creating this. I think there have been some notes in comments that mention having to make several updates

• T15016: Update default storage namespace
• T15013: Better handling of node/npm installation for Aphlict, more comments in D25004, D25006

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.

I've used both docker containers and vagrantfiles for development, though not too extensively. In my experience they're both pretty involved for something that requires multiple services running. I think vagrantfile might be a little more accessible for developers. Using docker will eventually require additional understanding of docker/docker-compose and how containers interact whereas virtual machines I think are easier to reason about. For example I think it will be very common for a developer to want to get to a command-line on the system running their phorge services. Doing so with docker requires knowing which container you want (docker container ls) and running an interactive bash (docker exec --it {id} bash). With vagrant it automatically sets up ssh (and handling keys, somehow) so you can do something like vagrant ssh and it drops you into bash on a single machine that has all services running.

I've been working on a diff for this. Diviner is rough as it doesn't parse book titles or descriptions using Remarkup, so I'll also have to make a change to the Diviner engine as well...

Ah, yea... I actually have a change in our company's Phabricator instance that customizes the rendering of titles on diffs and audits, though it doesn't use remarkup rendering on them but just optionally creates links to our external task system. I'm not sure what would be a good solution here, as using remarkup doesn't necessarily seem like the right approach.

I've copied the contents into L1 Phorge Vision Statement which allows us to track signatures

That sounds good to me. I'm hoping to get back to a new approach for T15006 later this week, in cooperation with upstream

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.

• Rebase
• Fix error mssage in HarbormasterCircleCIBuildStepImplementation
• Add some comments explaining what's up in HarbormasterExternalBuildableInterface

Thanks for the review @speck , I'll rebase this and update.

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?

@willson556: phorge-devcontainer looks awesome. I'll try it out asap. I may be able to contribute as well, I've got a bit of experience building reusable development environments.

Caddy looks interesting - if you get it going, can you make a small instructions writeup?

Yep! I have it setup where almost everything is configured using environment variables/docker secrets. Currently the only configuration file that needs to be passed into the Phorge container is for Configuring Outbound Email since that can vary quite a bit. NGINX has a config file but the only modifications it needs are sections to be commented/uncommented if it's used for SSL termination, otherwise everything is set using environment variables. Of course NGINX could be swapped out for your web server of choice. I might look into providing a example that uses Caddy for the web server as it has native support for ACME and should be pretty easy to do.

I like it

In T15012#766, @speck wrote:

Note that I've been discussing with epriestley in the upstream regarding rebranding. His suggestion regarding diviner is to introduce a ReMarkup rule that allows for using e.g. ${{{ project.name }}} which is then swapped out during rendering, allowing the diviner documentation to reference a non-descript project name that is filled-in when generated/rendered. I think that's something we should consider, and I think will be something that gets submitted/accepted in the upstream.

In T15014#769, @speck wrote:

I'd like to volunteer to help maintain the releases if that's OK. It's something I absolutely love (tracking changes and maintaining documentation) and I think it'll be a great way for me to support this project.

That sounds great to me! I'm a fan of having someone be the primary release engineer/manager and your volunteering would be very valuable for the project.

Ship it!

Image licenced CC-BY-SA-2.5

I like the current version :)

Nothing to comment on: It’s great!

I'd like to volunteer to help maintain the releases if that's OK. It's something I absolutely love (tracking changes and maintaining documentation) and I think it'll be a great way for me to support this project.

That sounds great to me! I'm a fan of having someone be the primary release engineer/manager and your volunteering would be very valuable for the project.

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)

In case you're not cc'd on the task, refer to T15006#765

Note that I've been discussing with epriestley in the upstream regarding rebranding. His suggestion regarding diviner is to introduce a ReMarkup rule that allows for using e.g. ${{{ project.name }}} which is then swapped out during rendering, allowing the diviner documentation to reference a non-descript project name that is filled-in when generated/rendered. I think that's something we should consider, and I think will be something that gets submitted/accepted in the upstream.

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

Since there is no objections to the release process here (only discussion around the use of tasks), I'd like to propose that we begin promoting to stable shortly. I'd say let's cut the Monday following the week of the release, so the next release will happen July 5 for version 2021.26 (2021 Week 26).

Thanks for the suggestions - I've updated the document to address them.

The vision statement really is fantastic.

For reference: I've been relying on this docker container for docker-compose as well as kubernetes based deployments and it has been a delight to work with.

Just got a response from James Daniel (here's some of his work), he'd like to get in touch with leadership directly, if anyone's interested they can email him or send him a DM on twitter.

I've made some updates to the vision statement document to try and bring it closer to completion. I've incorporated the rest of the outstanding notes and addressed the current comments.

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

Per discussion on Zulip.

This can be achieved easily in practice by creating an extension for arc

In T15024#725, @speck wrote:

This is an area I'm interested in with regards to Harbormaster's future, though I don't have any clear designs on anything. The concept of a merge queue is interesting and something we've started looking into at my company. Here are some resources we've looked at:

• Successfully Merging the Work of 1000+ Developers, article from Shopify
• Keeping Master Green at Scale (PDF), a paper from Uber. Related HackerNews Discussion.
• Merge Train, GitLab's tracking issue for this feature
• BORS, a GitHub merge bot
• Zuul, a "Project Gating" system to drive CI. Relevant pages on Project Gating and Zuul Concepts

Are we reasonably ok with what we have in the google doc?

Are we reasonably ok with what we have in the google doc?

So, just to clarify, as I realize that my original problem statement is a bit too restrictive: I meant How do I ensure that what someone lands is what was reviewed in the corresponding diff in a rather flexible way:

This is an area I'm interested in with regards to Harbormaster's future, though I don't have any clear designs on anything. The concept of a merge queue is interesting and something we've started looking into at my company. Here are some resources we've looked at:

• Successfully Merging the Work of 1000+ Developers, article from Shopify
• Keeping Master Green at Scale (PDF), a paper from Uber. Related HackerNews Discussion.
• Merge Train, GitLab's tracking issue for this feature
• BORS, a GitHub merge bot
• Zuul, a "Project Gating" system to drive CI. Relevant pages on Project Gating and Zuul Concepts

In T15024#720, @eax wrote:

In T15024#716, @avivey wrote:

The plan upstream was to (eventually) have arc land trigger T182, and do the whole thing server-side.

We do this at $employer. There is even a button in the web UI to land. We use the staging area revision + drydock + harbormaster to good effect.

In T15024#718, @Ekubischta wrote:

diff breaks master after rebase

Is there anyway at all to determine which commit a revision diff was compared to, and "if this is not HEAD" don't allow the land? (forcing users to re-base and resubmit their diff?)

I am not sure how bad this would gum up everything and/or in high-volume environments...nothing ever gets landed...

In T15024#716, @avivey wrote:

For the "diff breaks master after rebase" situation - the only solution for this is to have the CI run a rebase before running the tests, or have the CI part of the Landing flow, allowing it to block the push. This does slow the Landing situation, and makes it basically impossible to parallelize, but it's probably worth it if commits to a specific repository aren't very frequent and the CI is fast.

In T15024#716, @avivey wrote:

The plan upstream was to (eventually) have arc land trigger T182, and do the whole thing server-side.

There's also the point of users being used to arc land pushing code from their machine, so switching its behavior to delivering different code could have adverse UX.

diff breaks master after rebase

The plan upstream was to (eventually) have arc land trigger T182, and do the whole thing server-side.

@speck A possible path forward here - We will end up with new revisions, but that is good!

There are still a hundred or so more locations that need updated

In D25002#451, @avivey wrote:

If you can break it to one diff with the new method/css stuff and one or two string changes, and several with only string change, we can just review it and land them one at a time.

I can get a script to split a commit into smaller commits, so if you split it to "new code" and "everything else", the other breakdown would be easy.

If you can break it to one diff with the new method/css stuff and one or two string changes, and several with only string change, we can just review it and land them one at a time.

Attacking a few more instances while searching '.*\s+Phabricator\s+.*'

As a note there are some translated text areas around these changes which I've updated in D25002: T15006: Replacing external-facing trademarks/assets

As a note, when I'm searching for instances of "Phabricator" to swap out I review the entire file and not just the search result instances so all current changed files should be fully updated.

Did a search for pht\('.*Phabricator.*' to find places where "Phabricator" appears on the same line as pht(.
Updated T15006 with additional notes about other things that will need updated.

Searched for pht('Phabricator to find a few more instances to update.
Added a few notes to T15006 about non-translations which we will need to update.