Is it possible to pick a branching off point?

Isn't Centos End of Life soon?

The Herald rule should be project specific. If X happens then move task to Project->Column

I think both solutions work well

There's also the point of users being used to arc land pushing code from their machine, so switching its behavior to delivering different code could have adverse UX.

diff breaks master after rebase

@speck A possible path forward here - We will end up with new revisions, but that is good!

D25012 solves it, but I wonder if we should just exclude it from the "type": "text" linters

We could move this from the global exclude to just the specific linters (like the txt linter, etc.) - That would be a reasonable request

In T15021#564, @avivey wrote:

There might be a way to explicitly define it as generated, which (used to) exclude it from lint.

In D25002#410, @avivey wrote:

Could we...

What can I do to Help? -

A few final thoughts here as well

I second everything @speck says here.

Cool script @avivey! - I ran it (see P2) and see that we have a large task at hand...

I feel we should revert this change from master and back into a revision

I have a lot of concerns about what is happening with these Harbormaster updates. I believe them to be good strategy, and should be welcomed, however..............

T15011 discusses some of this...

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.

One thing to consider are installs where the database is being queried outside of Phabricator - anyone doing data analytics or other tooling that interacts with the database directly would be affected by this change.

In D25006#220, @deadalnix 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

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

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

What happens if

Refs the discussion here T15011#386 and Aphlict

In T15011#390, @speck wrote:

The documentation for installing Aphlict instructs you to npm install ws in the support/aphlict/server/ folder but it looks since that documentation was written newer versions of node/npm will write out package-lock.json which the repository is not setup to ignore. We'll need to add that file to the .gitignore file I think.

In D25003#88, @speck wrote:

This and D25001: T15006: Update .arcconfig to point to we.phorge.it are duplicates. I tried to land it this morning but ran into issues with the land process that I didn't have time to work out

A few things @willson556

In T15011#370, @willson556 wrote:

I actually started on a VSCode Devcontainer based solution on my GitHub: https://github.com/willson556/phorge-devcontainer

It is working pretty well with notifications and repository hosting both configured out of the box. My only concern with the config at the moment is that it's very much setup for development -- we would want to clearly document that it is not to be used as a starting point for a production docker-compose setup!

Any feedback would be appreciated!

In T15011#363, @speck wrote:

We should consider a Vagrantfile in place of docker containers. I think it will be more approachable to newcomers having a single VM with all the services/configurations setup compared to managing multiple containers.

Separately, developing on Windows has its own complications

I have some step by notes in our internal instance for getting SSH going - If you get stuck let me know and I will parse them into a public readable format

In T15000#277, @avivey wrote:

Also won't let me push, because something thinks it's a non-fast-forward (it is, unless I'm drunk):

From IRC a while back, for reference:

In general, the Welcome message stuff (And most of the concerns I outlined in T15003#216) will be taken care of in a new root / webpage(s) that will live at phorge.it and/or www.phorge.it - See T15000#234 for some background discussion

Just to keep this here for posterity

my vote would be phorge.it - simpler, easier to market, easier to say and easier to link to. - You could auto-redirect various common www., secure. etc.

+1 for demo instance! - Phorge Playground or something like that

So - If I am a brand new user that comes across this main Phorge page

Welcome to Phorge. Phorge is an open source, community driven platform for collaborating, managing, organizing and reviewing software development projects. You can learn more about the features of Phorge [here] and how to install Phorge [here]. You can ask for help [here] and [here] and you can learn about contributing to Phorge (here)

I feel that the first center-panel should be a "Welcome" panel. This panel would in the shortest amount of text possible :