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

Make changes based on code review comments.

Couple tiny nits and otherwise LGTM!

TBH, I don't think we need to revise it, especially not at this time. It's been working. If we find there are problems with it later down the road, we can revise.

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.

In D25006#220, @deadalnix wrote:

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

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

Abandoning for D25006

Wouldn’t the owners package only cause revisions to be marked, but wouldn’t that leave non-revision commits t not be handled? The herald rules act upon incoming commits rather than ensuring every revision is reviewed.

In D25003#206, @speck wrote:

I updated the herald rules to use O1 so it should work fine next time

I updated the herald rules to use O1 so it should work fine next time

Hmm try with this? There are some nuances I think to work out with the herald rule

Typo

In D25004#177, @Ekubischta wrote:

[...]

hmm - I cannot land this revision?

Will need this accepted again by Blessed Committers

Updating revision

In D25004#152, @deadalnix wrote:

Without package-lock.json, it is not possible to deploy a consistent set of dependencies resolution - they might change any time any one publishes a new package, which creates a lot of problems for reproducibility.

Test and Lint coverage?

In D25002#160, @deadalnix wrote:

As an asside, you might want to split up the logo rename part of that diff in another diff, this should be able to get in eight away, and there is no reason to wait on a resolution for the translation business to move on with it.

As an asside, you might want to split up the logo rename part of that diff in another diff, this should be able to get in eight away, and there is no reason to wait on a resolution for the translation business to move on with it.

@eax I created O1 for that purpose.

While I'm not super familiar with this setup, it is customary in the node space to commit package-lock.json int he repository. If it is intended to put stuff in there which are not to be committed at all - the folder is a placeholder - then it is best to ignore the whole folder. If committing what's in there is intended, then package-lock.json should be included.

In T15004#425, @speck wrote:

Currently rP and rARC only allow Blessed Committers to push - with those herald rules in place should we open that up?

Still need to search for instances of Phabricator appearing anywhere within quotes. Testing all this will be fun.

• Revert the logo and favicon (but keep logo rename)
• Added PhabricatorApplication::PROJECT_APPLICATION_NAME to default to Phabricator
• Updated instances of 'Phabricator' to use the new constant instead

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.

Updating comment per discussion

Currently rP and rARC only allow Blessed Committers to push - with those herald rules in place should we open that up? Maybe we should have a separate group "Contributors" for anyone who wants to submit revisions for approval? Or should it be opened to any user?

One thing that I think distinguishes these changes from T15006: Re-brand Phorge is that those changes are mostly intended to be submitted upstream in the hopes Phabricator accepts changes which enable more-easily re-branding the project. For Diviner I don't think that's something we can do since I'm guessing all the book content is effectively static.

In D25003#134, @speck wrote:

@Ekubischta it looks like @chris added you - could you verify your email? I'm also thinking anyone in the "security" or "blessed" groups should turn on MFA as well.

Oh, excellent! Thanks for looking into that.

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?

Since we're planning to eventually host more-open/accessible community repositories I created these as separate object rules instead of as a global rule

I created H7 Guard Phorge Repo with Blessed Committers and H8 Guard Arcanist Repo with Blessed Committers to guard rP and rARC

(It's all in src/docs and can be generated with ./bin/diviner generate)

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.

@Ekubischta it looks like @chris added you - could you verify your email? I'm also thinking anyone in the "security" or "blessed" groups should turn on MFA as well.

In D25004#131, @tobiaswiese wrote:

I have some concerns regarding the new comment, as these files don't really belong to aphlict, but are npm npm artifcats. If node-ws is installed via e.g. the system package manager (which is probably the better idea anyway), these files/folders won't be created.

Fair point on being precise with the terminology.

I have some concerns regarding the new comment, as these files don't really belong to aphlict, but are npm npm artifcats. If node-ws is installed via e.g. the system package manager (which is probably the better idea anyway), these files/folders won't be created.

In D25004#121, @Ekubischta wrote:

Will this cause a conflict? - I feel like it will..?

I created T15013: Better handling of node/npm installation for Aphlict for further discussion

Will it cause a conflict or ask the user to commit or stash untracked changes? But yeahhhhhh, will need some human intervention...

@speck @avivey Can you add me as a Blessed Committers ??

What happens if

The problem with package-lock.json is, that it either generates noise in the working copy (it just changes its content a lot of times during normal operation). And it needs an update every time a dependency (even indirect) got an security related update because production installs will otherwise not pull the updated dependency in.

Yea it probably won’t have an effect until they run npm install/ci. We could create those files and include. I’ll update

AFAIK package-lock.json is only used by npm itself, when deciding on which version to download. If no package-lock.json exists the version are taken to match package.json.

Just confirmed on another instance:

• Had an existing package-lock.json pinning ws to version 7.0.0
• Manually updated package-lock.json to pin to version 7.5.0 (did not actually update installed version of ws)
• Cycled Aphlict service
• Sent a test notification
• Received Web + Desktop popups