In T15014#929, @avivey wrote:

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

In T15030#949, @0 wrote:

There are some projects listed on the Phabricator Community Resources page. Would all of those be eligible for hosting here, or would there be some criteria to limit the number of external projects?

In T15000#888, @MacFan4000 wrote:

And also we perhaps should have an IRC channel such as #phorge on Libera. It would be possible to bridge it to Zulip.

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

There are some projects listed on the Phabricator Community Resources page. Would all of those be eligible for hosting here, or would there be some criteria to limit the number of external projects?

But why would we need to explicitly keep them? They already exist upstream...

My suspicion, though I hadn't thought through it much, is that it might be useful during migration periods where someone has the repository checked out and there's are clear linear branches of the phabricator development vs. phorge development.

Deleted the reference. All communication should happen on-instance.

FWIW I think the master / stable split happened upstream due to some planned deep rewrites. For our process I'd rather go masteronly and not have a separately stable or release branch.

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

I'm fine with whatever naming

In T15030#916, @dcog wrote:

In T15030#914, @avivey wrote:

We are planning on hosting community-driven extensions/projects (temp codename "Phactory"), either here or in a different domain; the idea is to have each project maintain their own repositories.

That sounds awesome! Cool name :) Curious, did this come up in Zulip? I need to log back in there.

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

(I should stop reading stuff before coffee. You'd think I'd know that by now...)

In T15030#915, @avivey wrote:

I'm thinking of hosting them here, giving each project to manage their own repositories, but having a more tight control over the creation of the repo (for technical reasons) and projects.
I'd like to only have projects that are clearly related to Phorge in the install, because we're not GitHub.

Having individual git repos also matches the common way extensions are installed (and my drafts for arc-install-eztension)

In T15030#914, @avivey wrote:

We are planning on hosting community-driven extensions/projects (temp codename "Phactory"), either here or in a different domain; the idea is to have each project maintain their own repositories.

I'm thinking of hosting them here, giving each project to manage their own repositories, but having a more tight control over the creation of the repo (for technical reasons) and projects.
I'd like to only have projects that are clearly related to Phorge in the install, because we're not GitHub.

We are planning on hosting community-driven extensions/projects (temp codename "Phactory"), either here or in a different domain; the idea is to have each project maintain their own repositories.

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.

Found that SVN works great for a monorepo... Does Mercurial as well?

Confirmed working fine in both Windows 10 and Linux Mint 20

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?

Looks like that worked I guess. I just went to phorge.it in my mobile browser and apparently redirected to we.phorge.it.

I sent @ toward 198.74.57.92 too.

Abandoned as this will not be needed with the upstream patch merged.

I landed this upstream.

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)

For this phorge instance, I think we should configure auth providers to allow logging in with Github/Google etc.

Looks like @deadalnix may need to update DNS:

$ dig phorge.it
[...]
;; ANSWER SECTION:
phorge.it.              0       IN      A       217.70.184.38

versus

$ dig we.phorge.it
[...]
;; ANSWER SECTION:
we.phorge.it.           0       IN      A       198.74.57.92

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.

I would like to officially submit myself as a Core Team member.

Are we supposed to make a similar lengthy statement?

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.

Here is a proof-of-concept for a Vagrant pattern.

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

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.

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.

I think both solutions work well

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.

Did another pass on it: only thing I found is a typo (which I'm not allowed to fix): extra space after "Opinionated" and before to column in the list under "What is Phorge".

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!