I'm going to look at trying to land this today. Additionally I created T15042 to avoid situations like this where the changes are accepted but don't get landed for some time.

Reference to the last Phabricator starmap prior to deletion. Phorge's starmap will likely align very closely with Phabricator's, initially.

With this change these log messages are being written out, even though the default of $this->quiet is true. I think this is because rebuild-map.php script unconditionally calls setQuiet() with the value it's passed from the command-line, however ArcanistLiberateWorkflow does not specify or pass in a quiet argument.

I think this looks good, and based on the (non-search-engine) conduit API stuff I'm familiar with I think everything looks correct.

Is there information about the IRC channel or Matrix channel on how to get set up? If there's chat I'll try to join in but I won't be able to be always-connected.

I added you both as well! Welcome to the team. If anyone has pre-existing functionality that they feel would be good to include in the upstream feel free to submit the changes. There's ongoing work (unfortunately slowly) to rebrand the project, but that's not holding up other changes at this time.

In D25015#633, @avivey wrote:

In this case I think the error text is agnostic of the instance of the dialog.

I was thinking about this use-case, which implies to me that the dialog author should be involved in the error text:

For the case of email headers

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

One other case where "Phabricator" appears is in HTTP and Email headers, e.g. X-Phabricator-XYZ. For a separate project wanting to update these I think a slow migration approach is needed, to allow recipients currently expecting the existing fields. I'm guessing there isn't a reasonable change here for the upstream.

Depending on how many of these we end up with, I think an email-header-prefix sort of config option might be reasonable.

Ah I did not look closely enough. Dang. We should be attaching the message to the view on the server then, somehow.

This looks good to me.

I added @dcog @codemouse92 and @mydeveloperday to the trusted contributors group. Glad to have everyone involved!

In this case I think the error text is agnostic of the instance of the dialog. From looking at AphrontDialogView I didn't see any obvious way to include additional fields/text that could be pulled out here on the front end. Looking elsewhere in this file (line ~297) it looks like some other generic text is used

if (!this._paused) {
  JX.$E('Resuming a workflow which is not paused!');
}

I'm not familiar with the search engine or legalpad frameworks but things look like they line up

The ubuntu/rhel scripts have been removed in the upstream (https://secure.phabricator.com/D21678). We can probably avoid making changes to those files as they should go away once we merge in changes.

The arcanist source in general seems to be split between fwrite(STDERR, $message."\n") and fprintf(STDERR, "%s\n", $message); I decided to go with the latter.

I think the latter format would be preferred as the formatting is more common elsewhere in the code, as opposed to concatenation.

I think this would be reasonable but I think it requires setting up an account on GitHub or Google on behalf of Phorge (rather than using a member's personal account). If someone wants to set up a GitHub/Google account for phorge we can set it up here. It'll require an email address though and I'm not sure how to handle an organization email like that.

I'm not a big fan of IRC because in order to look through history or pickup where a user last joined it requires individual users to maintain their own tooling/practices. The temp-community chat was the first Zulip chat that I've used, and installed the mobile app for. I thought Zulip worked pretty well and wouldn't mind continuing with that. I've used Matrix (Element?) briefly but didn't feel too strongly about it. It's probably worth mentioning that our current Zulip instance has ~135 members and we've still had ~1-2 new people join per week lately. Though there's not much actual discussion going on there.

Handling of merging upstream changes will probably lead to some challenging merges done by people who did not author the original changes in Phorge. I don't know what the best way is to work around this. Maybe if we regularly (daily?) pull in changes from upstream, merge into our own master branch which everyone lands onto that should mostly catch merge issues?

Would it be easy to change the prompt to be more descriptive with actions? It’s generally more clear to have the buttons read “Discard changes” vs. “Ok” or “Yes”

Yea I think it will be easiest to host this on the same server that's running we.phorge.it. If we're able to build it as an extension application for phabricator it can be setup in the same installation and then we can route the web server to host it properly.

If it's not worthwhile then let's not do it

nit-pick: maybe name them phabricator/master and phabricator/stable.

I'm fine with whatever naming

I was discussing with @deadalnix a bit and I think it would make sense to retain branches in our fork that represent the master and stable branches from upstream, but not be the primary branches we commit/land phorge into. That would allow us to keep synced with upstream's changes and regularly merge those in. I think operating in this way would also let us be a little more flexible with allowing other changes to be worked on and landed in the phorge branches without being blocked by the rebrand changes. Then at some point in the future the rebrand changes would come in from the upstream branch, merge in, and we could make an official Phorge release.

The future plans for the domain landing page are under T15008: Build Welcome Site. I'll close this out for now since the redirect is working.

I think it makes sense to host repositories here. If we go with monorepo what would general permissions be for something like that?

It looks like all @20after4 has to do is land that change into the upstream as it's approved. It might be better to have it land upstream then we pull in changes from upstream (there are a number of changes this fork is now behind on)

Thanks for pointing this out. I updated the link to the correct one. Somehow an extra hyphen appeared in the URL which I swear I had copied directly from the page.

Hm I tried updating the nginx configuration to do a temporary redirect to https://we.phorge.it but it doesn't seem to be functioning properly. Someone else with better nginx experience might need to lend a hand -- @Matthew maybe?

Are we supposed to make a similar lengthy statement?

Heh, I wasn't really sure what people were expecting so just wrote up some stuff to explain who I am and what my role will probably end up being.

After agreeing and signing the document I submit myself here as a core team member, officially.

@jupe thanks for pointing out the typo, I've updated to fix that.

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.

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

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.

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

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

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

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

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

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.

For this diff I'm going to continue the current approach of swapping Phabricator with %s and adding an argument, with the understanding that this might not be the final approach we take.

I took a bit of a further look and this does look like a solid refactor. I think in general we should also aim to add more documentation as we go along which will help to improve others' understanding of how things function. Since there's a lot of existing code that's undocumented I think adding class-level and method-level comments to any which are added or significantly refactored would be good to add for this.

In D25012#422, @Ekubischta wrote:

We could move this from the global exclude to just the specific linters (like the txt linter, etc.) - That would be a reasonable request

Thank you for checking out an example CircleCI, both with and without these changes! That gives a lot of confidence that these changes are pretty stable. I just did a quick look through the code changes but would like to sit down later and go through more in-depth if only to learn more about Harbormaster.

I think it makes sense to find some balance based off the impact of a change. If someone is submitting some code documentation changes or typos then I would personally be fine with not requiring a task as long as the diff itself can encompass the details and lints/unit-tests to account for syntax errors. What I'm worried about are larger changes which don't have tasks, as that means someone is putting time into larger changes without seeking input/discussion from others about how to approach the problem. Additionally it may also be possible that someone else is working on a similar change resulting in either duplicated or conflicting efforts.

@avivey has anyone been in contact with Evan that can reach out? I don’t really know of a way to reach him for this type of topic/project.

I would say let’s go ahead and make those changes. I’ll be on later tonight from a workstation and can make those changes then (~8hrs) if needed.