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.

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?

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

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.

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.

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

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

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?

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!

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)

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.

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

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

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

(I'm 100% with @speck on requiring tasks)

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.

I like the proposal above. Especially with having the core team "sign" a vision statement. The goal is less legalistic and more of ensuring we have a consistent view of the end product.

In T15014#676, @Ekubischta wrote:

A few final thoughts here as well

• Phorge was branched from Phabricator and T15000 was created 14 days ago - This is barely enough time to figure out some basic setup and infrastucture stuff let alone develop the strategy for an entirely new open source software project. Even further than this, this is forked from an already existing and stable project It is completely prudent to keep the brakes on for a sec while this stuff gets figured out

• Tasks before diffs...always... The task describes the issue and one or more revisions resolves this issue. The lift requred to create a task is so minimal that I am surprised that this is a point of contention

1. Create a task
2. Create a branch in form of Txxx-BranchName
   • Your revision will be automatically linked to the task - no manual work
3. Write your revision and comment Fixes Txxx in the summary
4. When you land your revision - Task is automatically closed

In fact, once arc work is completed for task handling, you can do arc work Txxx from the cli and it automatically creates the branch - simple and easy

What would be immensely worse, is a process that says "If the developer does not feel a task is required, then don't make one" - This is chaos.. If you have 10 developers, you will have 10 different versions of "when is a task required?" - This is solved simply by saying : "Make a task describing the issue, attach your revision to it"

, if one is to fix a typo in a comment, requiring that person to open a task, then open a diff linked to the task, than mark the task as resolves once the diff is landed would actually be harmful.

How? - Again, the work required to create a task is so minimal - We have literally spent more time discussing "should we create a task" then the time it takes to create 100 tasks

A few final thoughts here as well

Great! Thanks @Matthew .

In T15004#672, @speck wrote:

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.

In T15014#671, @avivey wrote:

In T15014#670, @deadalnix wrote:

Now, can we get a setup with CircleCI going so that we can test things?

Everybody else is busy with the rebrand/startup process. You should be able to create a free account and test from your own environment - I think that's how Evan developed it originally.

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.

In T15014#670, @deadalnix wrote:

Now, can we get a setup with CircleCI going so that we can test things?

In T15014#622, @speck wrote:

I'm redirecting the discussion from D25011 to this task

I second everything @speck says here.

From my notes

Just emailed/DM'd some people, I'll see who replies.