In T15001#980, @MacFan4000 wrote:

Just a note that Trusted Contributors can’t self grow beyond admins adding people currently as to add members you need to be able to edit the project. Currently only admins can edit the project.

In T15035#1008, @eax wrote:

FWIW I don't object to support or community channels off-instance but I do think we need:

• all decisions should be made on-instance
• we should have a culture of ensuring that any "interesting" discussions get recorded on-instance.

FWIW I don't object to support or community channels off-instance but I do think we need:

• all decisions should be made on-instance
• we should have a culture of ensuring that any "interesting" discussions get recorded on-instance.

I would certainly be happy to work with Libera staff to get the community registered.

I would like to be a part of the core team, and I've signed the document.

On a related note, tonight I discovered this UIExamples application (changing links from my Vagrant install):

In D25015#532, @speck wrote:

It’s generally more clear to have the buttons read “Discard changes” vs. “Ok” or “Yes”

I agree

Would it be easy to change the prompt to be more descriptive with actions?

For me, I think it might be on the hard side... and maybe add some bloat? Unless there is a styled generic confirm box created that maybe uses a callback instead of blocks execution...

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”

Thanks for accepting this. I can’t land it though, somebody with the proper permissions will need to do it.

It is a step forward, but considering how the URL could be factorized would be a plus, IMO.

In T15030#978, @20after4 wrote:

regarding a monorepo, I'm not sure if there is an advantage to that, I'm fine with individual repos. I currently maintain most of Wikimedia's extensions in a single monorepo but I'd consider splitting them out into individual repos if any one them were candidates for upstreaming.

Just a note that Trusted Contributors can’t self grow beyond admins adding people currently as to add members you need to be able to edit the project. Currently only admins can edit the project.

regarding a monorepo, I'm not sure if there is an advantage to that, I'm fine with individual repos. I currently maintain most of Wikimedia's extensions in a single monorepo but I'd consider splitting them out into individual repos if any one them were candidates for upstreaming.

I'd like to host https://github.com/wikimedia/phabricator-antivandalism here, perhaps under a new name.

The Caddyfile boils down to

In T15030#972, @avivey wrote:

A space-zombie game that can report high-scores to IRC, Slack and Phorge.

Here's the terms I've been thinking of for accepting a project to Phactory:

1. Directly related to Phorge in a significant way:

Good: Module for integration with some other system; New Phorge app that does something reasonable; scripts for administration work.
Bad: A space-zombie game that can report high-scores to IRC, Slack and Phorge.

Checking the Wikipedia entry for GDPR at https://en.wikipedia.org/wiki/General_Data_Protection_Regulation it mentions that this regulation or other similar ones have been enacted in:

Of course since Phorge itself is a public project with, potentially, UK/EU contributors the signup/login page should really display such a warning.

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.

I think that the best choice is to keep everything in one place, so create the presentation site on the same infrastructure of we.phorge.it

sorry for late reply. I can start working on it now. Where will be it hosted? Do you have some preference? We can use also my company infrastructure and change DNS record for a 3rd level to point to the IP.

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".