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?

I think this is complete.

I'm going to call this done, since we have a stable dashboard set up now.

Looks good to me!

Looks good to me.

Address code review comments

In D25009#285, @20after4 wrote:

Shouldn't we also think about changing the name of arcanist or does it make sense to have a fork with the same name?

Both revisions are landed. We just need a pull on the upstream install to regenerate the documentation. @chris could you do the pull so I don’t break anything?

Alternatively, we could include a one-time migration step that sets the default storage namespace to the database as part of the storage upgrade step… this would ideally be silent.

Fix a link that will break once we regenerate the documentation.

I created a change log just so we could begin documenting changes as they happen.

Make changes based on code review comments.

In D25006#216, @Ekubischta wrote:

My only concern here is that technically this introduces issues for any user install that already contains an untracked package support/aphlict/server/package-lock.json

I feel that this needs to be addressed in "release notes" or "upgrade notes" somewhere - However, we do not yet have this process defined?

This was handled by Phacility/Phabricator with their changelog and process for promoting stable

In T15012#423, @speck wrote:

For Diviner I don't think that's something we can do since I'm guessing all the book content is effectively static.

In T15000#408, @speck wrote:

It looks like Diviner was used to generate documentation however a lot of the documentation still refers to "Phabricator". We'll probably want a separate task just for reviewing and updating all the documentation to make sure it's appropriate.

Btw where is the source for the diviner books and how does it get generated?

In T15008#278, @avivey wrote:

I think we want an Application in an Extension...

Do we want to make this an application or an extension? I'd lean toward the latter, it might be a good one to seed our new extension library with...

Sorry about the spam... I've gone ahead and made all the component projects of Phorge public. Is there anything else we need to do here?