For reference: I've been relying on this docker container for docker-compose as well as kubernetes based deployments and it has been a delight to work with.

This can be achieved easily in practice by creating an extension for arc

In T15024#725, @speck wrote:

This is an area I'm interested in with regards to Harbormaster's future, though I don't have any clear designs on anything. The concept of a merge queue is interesting and something we've started looking into at my company. Here are some resources we've looked at:

• Successfully Merging the Work of 1000+ Developers, article from Shopify
• Keeping Master Green at Scale (PDF), a paper from Uber. Related HackerNews Discussion.
• Merge Train, GitLab's tracking issue for this feature
• BORS, a GitHub merge bot
• Zuul, a "Project Gating" system to drive CI. Relevant pages on Project Gating and Zuul Concepts

So, just to clarify, as I realize that my original problem statement is a bit too restrictive: I meant How do I ensure that what someone lands is what was reviewed in the corresponding diff in a rather flexible way:

This is an area I'm interested in with regards to Harbormaster's future, though I don't have any clear designs on anything. The concept of a merge queue is interesting and something we've started looking into at my company. Here are some resources we've looked at:

• Successfully Merging the Work of 1000+ Developers, article from Shopify
• Keeping Master Green at Scale (PDF), a paper from Uber. Related HackerNews Discussion.
• Merge Train, GitLab's tracking issue for this feature
• BORS, a GitHub merge bot
• Zuul, a "Project Gating" system to drive CI. Relevant pages on Project Gating and Zuul Concepts

In T15024#720, @eax wrote:

In T15024#716, @avivey wrote:

The plan upstream was to (eventually) have arc land trigger T182, and do the whole thing server-side.

We do this at $employer. There is even a button in the web UI to land. We use the staging area revision + drydock + harbormaster to good effect.

In T15024#718, @Ekubischta wrote:

diff breaks master after rebase

Is there anyway at all to determine which commit a revision diff was compared to, and "if this is not HEAD" don't allow the land? (forcing users to re-base and resubmit their diff?)

I am not sure how bad this would gum up everything and/or in high-volume environments...nothing ever gets landed...

In T15024#716, @avivey wrote:

For the "diff breaks master after rebase" situation - the only solution for this is to have the CI run a rebase before running the tests, or have the CI part of the Landing flow, allowing it to block the push. This does slow the Landing situation, and makes it basically impossible to parallelize, but it's probably worth it if commits to a specific repository aren't very frequent and the CI is fast.

In T15024#716, @avivey wrote:

The plan upstream was to (eventually) have arc land trigger T182, and do the whole thing server-side.

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

The plan upstream was to (eventually) have arc land trigger T182, and do the whole thing server-side.

@deadalnix's I like option 3 from a UX perspective - and it also lets us hold on this issue for a little while, without making things worse.

I am not a fan of adding interaction to the upgrade process but we can use the "setup issues framework" or an approach similar to @deadalnix's comment.

Just to add clarification around T15009: Evaluate legal organization format ("Foundation"), we can opt to create our own organization instead of joining an existing foundation however that involves a lot more paperwork, submissions, legal stuff, etc. The foundations are a means for speeding along that process, where Apache Foundation, Linux Foundation, etc. create their own non-profit organizational legal entity then "adopt" sub-projects which automatically inherit and become part of their entity as long as we abide by their agreements, largely focused around providing open source projects run by open source communities. In turn they provide benefits like being the actual legal entity that owns the trademarks/copyrights/assets for the project, some even offer to be owner of domain names etc. along with providing some legal assistance for e.g. open source license law or even for initially acquiring trademarks/copyrights.

I'm redirecting the discussion from D25011 to this task

@chris Option 3: when upgrading an existing instance, and *IF* the storage.default-namespace is not set explicitly, prompt the user.

Is this change necessary?

I think that for the time-being, we should just continue the stable/master approach, because we have a lot of other things to do.
We can always open this later if we feel a need.

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?

Can I please have access to Release Process ?

fwiw the old upstream workflow has been very easy to follow as a downstream fork maintainer so I like keeping it mostly unchanged.

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.

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.

One other option, if we're going to provide a migration guide, par of that could be setting the storage namespace... Brain fart and forgot that'll be something we do. But that'd let existing installs continue to use their Phab namespace and new ones the Phorge one

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. I’m not suggesting we never consider it but it would be better if we can provide tooling/scripts where possible or even create a wider time span for migration. Would MySQL/MariaDB support aliases of some sort? Or maybe there’s a way we can support both namespaces for a time

Confirmed this does indeed break existing installs relying on the default. What options do we have to work around this? Couple that come to mind might be:

• Add a new SQL patch that runs RENAME TABLE old_db.table_name TO new_db.table_name for every Phorge DB and table.
  • Con of this is that it may require a new GRANT ALL PRIVILEGES ON [...] statement based on how each install originally set things up (e.g., granting ON *.* versus ON phabricator%.*)
• Add a line in the release notes telling users to ./bin/config set storage.default-namespace phabricator if they're using the default namespace
  • Con of this is it's an out-of-band upgrade step that relies on instance maintainers reading the release notes and not setting and forgetting an upgrade script in a crontab on the assumption that stable generally is pretty stable
• Leave the default storage namespace as phabricator

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

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

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.

Ah I wasn't aware of that option. I created D25004: Update .gitignore to account for package-lock.json if we want to update the .gitignore

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 T15011#386, @Ekubischta wrote:

A few things @willson556

• Untracked file in phorge source support/aphlict/server/package-lock.json

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!

Emails have a bunch of X-Phabricator-* headers, for configuring rules in mail clients.

• We may want to allow installs to keep it as Phabricator for compatibility

Checking imagemagick

For the time being I've modified the wordmark configuration to manually upload the logo file https://secure.phorge.it/config/edit/ui.logo/

@avivey the current installation includes a commit I had made on the github fork which made minimal changes to rebranding. Ultimately I think we'll want to scrap that commit but it should have replaced the eye icon with a lovely heart.

BTW, it's intentional that the place of the logo is currently a blank space, right?

• Emails have a bunch of X-Phabricator-* headers, for configuring rules in mail clients.

also, if we want to start with something super generic, we could probably get away with just a 'p' wordmark or an icon from fontawesome.

Everyone I've emailed is busy right now, anyone else know some good designers?
@cburroughs: an open contest sounds like it could work.

./NOTICE has some legal text we might need help with.

I don’t think it has really started yet. I had some changes on GitHub which I’ve abandoned but I think those changes were copied into the install here.

Is this happening on rP, or on github somewhere?

I know some projects have had success with having the logo be an open contest. Perhaps we could use something super generic clipart placeholder to start, and then try that?