It is almost certainly due to some DNS config. Modern email provider expect a ton of different config in there, and they are quite tricky to get right.

I've been think about what to do with this for a while, and I have to say, it's a hard one.

It is a step forward, but considering how the URL could be factorized would be a plus, IMO.

I sent @ toward 198.74.57.92 too.

Are we supposed to make a similar lengthy statement?

• Rebase
• Fix error mssage in HarbormasterCircleCIBuildStepImplementation
• Add some comments explaining what's up in HarbormasterExternalBuildableInterface

Thanks for the review @speck , I'll rebase this and update.

The vision statement really is fantastic.

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

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 D25002#451, @avivey wrote:

If you can break it to one diff with the new method/css stuff and one or two string changes, and several with only string change, we can just review it and land them one at a time.

I can get a script to split a commit into smaller commits, so if you split it to "new code" and "everything else", the other breakdown would be easy.

So I setup an instance and a dummy project with CircleCI integration.

Great! Thanks @Matthew .

In T15014#671, @avivey wrote:

In T15014#670, @deadalnix wrote:

Now, can we get a setup with CircleCI going so that we can test things?

Everybody else is busy with the rebrand/startup process. You should be able to create a free account and test from your own environment - I think that's how Evan developed it originally.

In T15014#622, @speck wrote:

I'm redirecting the discussion from D25011 to this task

@speck What you have here seems reasonable to me. Can you propose this upstream and see how it goes?

In T15008#573, @jupe wrote:

should we also start working on the content?

How many of them are there? Eyeballing P2, it's of the order of 500. There are 5 people in this task, we can do 15/day and be done in a week. That doesn't sound intractable if we are all willing to chip in.

In D25011#376, @jupe wrote:

To add my two cents on this:

Of all the point raised, only the one about testing seems to fall in the category of good process, and even then, the part on unit tests still kind of falls in the wrong bucket

I have the feeling that the issue at hands is a different perception of priorities. I agree with you on the fact that we should be goal oriented: right now different people might have different goals in mind.

In D25011#370, @avivey wrote:

@deadalnix: want to move the bigger discussion to a ny task? I'm on a mobile right now.

In D25011#365, @chris wrote:

Doesn't CircleCI have some API contract that we can stub out? If the requests + payloads Harbormaster is sending out to CircleCI endpoints pre- and post- this patch are unchanged, and those conform to CircleCI's published API spec, then like, (1) that's all testable, and (2) that's a good assurance that nothing's breaking as a function of this patch that wasn't already broken prior to it. Saying something can't be tested because it calls to an external system feels like a little bit of a cop-out. We can't control what CircleCI does with a request Harbormaster sends, and that's a totally fair point, but we can control what Harbormaster sends to it and when, and ensure that what we're doing conforms to their published documentation.

In D25011#366, @avivey wrote:

One point that you raised and I disagree with: we do have lots of users right now. We (I) consider all the installs of Phabricator to be Phorge installs in-waiting; we want to keep compatibility there, for a while yet - to ease their transition.

And in addition, there's a limited amount of attention we all can allocate to the project; if we spend time reviewing this change, we take that time away from the bootstrap process.

In D25011#365, @chris wrote:

In D25011#358, @deadalnix wrote:

Slowing things down is rarely a good idea ever - at least for the reasons external to the patch in question, rejecting a patches because it's not good if obviously just fine. I reject that point outright.

How is IP assigned currently? We have no CLA, no legal entity stewarding the project. Are we inviting something like the SCO-Linux dispute (obv a worst-case scenario)? What happens if one of our employers takes an interest and attempts to assert ownership of any IP we've individually contributed? Are we at risk of infringing on Phacility trademarks by actively developing, extending, and offering as our own something that, to an end user, ostensibly still calls itself "Phabricator" in 1500-odd user-facing places across the entire application? Do we even know?

100% IANAL, I have no subject matter expertise in any of this. I fully admit I could just be catastrophizing. If the answer to all this is, "Yup, everythong's a-ok, carry on", then that's awesome. But I don't think we have any answers yet, and that feels like it could potentially become problematic down the road. The cost of doing our due diligence here is a couple weeks' delay on some active development; the potential cost of not doing it is we have to rip out functional parts of the codebase and rewrite them because we messed up on IP assignment and licensing.

Do lint and fix error raised by the linter

A few things on here.

I would like to note that France has what the local law calls association loi 1901, which is very advantageous for a open source projects. In short it is an entity that can own stuff, accept donation, but cannot do for profit operations. Projects such as VLC and ffmpeg are using this. The requirement are very lax (you basically need to have an address somewhere in France for administrative bullshit) and have at least 3 founders. They don't need to be French or live in France, in fact, last time I checked, you could even do one as an illegal emigrant, which I found funny. I had a long chat with Jena Baptiste Kempf who created VLC about this for the last big open source project, but we ended up going for a structure in HK because we had Chinese users and donors and that was easier administratively this way. Chinese special case excluded, this was by far the best option we had.

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

I see that this has been added to the changelog already here: https://we.phorge.it/w/changelog/2021.25/ . Fantastic!

I landed the code, but leaving the task open because we need to add a release note whenever we know where they go.

rebase

I'm going to land this one as to not wait on things that are not sorted out, with the obvious note that a release note would be advantageous.

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.

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 D25003#206, @speck wrote:

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

Typo

In D25004#177, @Ekubischta 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.

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

No need to apologize, i wasn't super clear myself, so let me try to make my point in a more cogent manner. The main thing that bothered me with what happen is that our default should be to use the phorge's default (that I happen to find good myself, but it is not super relevant to the point). This comes down to dogfooding. The default configuration is what we are going to put into people's hand. We must ensure this is as good as possible for as many users as possible right out of the bat. This will never happen if the standard phorge install doesn't use the default, because what's out of sight also typically is out of mind.

Also, S1 isn't public, contrary to what the name says, so this effectively just changes the error message at the moment.

This nevertheless regressed the dashboard for everybody vs what was before. I'm sorry but I don't want to be welcome to create my own dashboard with the information I see fit on it, because I had one that was pretty good to begin with. You just broke everybody's dashboard. If it is for logged out users, and you don't want to put it up now, then just park it somewhere.

In T15007#182, @Matthew wrote:

We are holding off, until other tasks in T15000 are complete.

Changes:

• differential: default view policy: public
• diffusion: default view policy: public and default push policy; blessed committers
• maniphest: default view policy: public and default edit policy: task author or trusted contributors.
• project: default view policy: public
• paste: default view policy; public
• countdown: default view policy; public

So I edited policy.allow-public and set it to true in the DB.

I'm going to have to be honest here. While this is more appropriate for logged out users, this is a net regression for a regular user.

So some feedback from my experience doing this in the open.