As of right now, we have made no changes to the database and other "internals" - our work has been focused on rebranding as "Phabricator" is a trademarked name. For this reason, a rough migration path would be to check out the master branch of rP, copy the config directory from Phabricator to Phorge, and then point Phorge to your Phabricator database. I have tested it myself locally and it appears to work, however; if you have any issues feel free to ask a question on Ponder here and we can get back to you!

Related to T15090: CVE-2022-24765 - Multi-user Git Privilege Escalation perhaps? Revisions are stored in the database that's why they're viewable, but the main repository page requires a call to git.

@dtf I've added you to the Trusted Contributors project, so you should be able to edit the page now.

In T15090#2126, @golyalpha wrote:

apparently, Ubuntu maintainers have backported a patch for the older version of git in 20.04 LTS, downgrading to version 1:2.25.1-1ubuntu3 seems to be a temporary workaround, losing the following patches:

We need to cherry-pick and import the changes Evan made into the Phorge repository as well...

As discussed in {E2}, we might add temporary banners to Diviner to state that we are rebranding. This would allow some time for us to handle the code rebrand and address the underlying Diviner issues before we edit everything twice.

As discussed in {E2}, we will be implementing this to control spam for now. If this doesn't work, we will revisit this discussion.

In T15012#1283, @MacFan4000 wrote:

I will note that also the tech docs aren’t fully generated since there should be docs for most of the phorge/phabricator classes. Also the arcanist docs aren’t generated at all.

Thanks for your comments! Namespacing might be useful, we would have to figure out what that looked like. I was thinking "/book/group/link" as that would be pretty natural (and is very close to what Diviner does already: "/book/group/filename"). It would also allow for us to eventually make Diviner widely useful, see secure: T4558. However, that is a broader discussion that should probably wait...

I am closing this, future meetings are scheduled now. See March 21, 2022 for more information.

In D25035#1059, @speck wrote:

Real quick before landing -- should this change be made here in PhabricatorUser or would it be sufficient in PhabricatorPeopleProfileController? Placing it here affects the profile at the data model source which would likely cause the same blurb-scrub in any other location it might render, but it might also cause problems in areas which need to access the profile data for other reasons other than rendering, e.g. if a profile gets copied/cloned in memory then this might result in losing the profile data altogether. Updating only PhabricatoPeopleProfileController to call cleanupProfile() instead of within PhabricatorUser would only scrub it at the time it's being rendered (to the profile page at least).

In D25035#1051, @speck wrote:

I'm having trouble landing this, I keep getting 403 errors. I suspect it's a local configuration issue, though...

All that should be required to land is being in Blessed Committers I think, which you are a member of

Address code review comments

In T15080#1970, @speck wrote:

Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?

Thank you for the review, @avivey !

Closing this task now, to prevent it from turning into a perpetual task.

As discussed in {E1}, we will actually add another action aside from "Disable Account." This action will mark the account as a spammer, which will take the following non-distructive actions:

The choice to not allow administrators to edit profiles is a strange one... at the very least, we should probably upstream Mukunda's patch.

Thanks for the ping, @MacFan4000. I am in and out because this is my last full-time semester, but I do see the room and have been checking in on it.

In T15001#1011, @MacFan4000 wrote:

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.

IMO the edit policy should be set to Project Members. This way it’ll be able to self grow. :)

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

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

Per discussion on Zulip.

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

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 T15004#650, @speck wrote:

This is my understanding of the items in the description currently, please indicate if this is not correct

Security - I think this may have originally been intended for tagging items which are related to security issues that need addressed, such as vulnerabilities in the project. I think this is a tag that anyone could use when submitting issues.
Security Viewers - This is used to wall off items that should be restricted from public viewing, namely security reports, putting things into {S2}
Blessed Committers - The group of people who can push changes to the upstream

In T15014#495, @Ekubischta wrote:

In T15014#446, @speck wrote:

I created Release Process in our internals wiki to start the documentation on what the release process would look like, based on some of those commented. As we flesh out the plan I’d like to update that.

Can you give me access to see that document?