This is probably ultimately the same as T6878 -- T6878#167273 has the current plans here.

Sorry, we don't have the resources to help users debug setup and environmental issues which we can not reproduce. The documentation is extremely clear about this. See Support Resources. Bug reports must have clear, complete, self-contained reproduction steps. See Providing Reproduction Steps.

I followed your instructions on a new, clean Phacility test instance, but the issue did not reproduce for me. Here's a screenshot:

This report doesn't have enough information for us to help you solve the problem. See Providing Reproduction Steps for help with providing reproduction steps.

You can update the phabricator_user.user table and remove the isMailingList flag from the account, something like this:

Some of the changes associated with T4292/T10748 -- principally, D15742 -- have pushed this forward, although it doesn't really do anything yet:

Every service on secure is now supported by a redundant version in a separate AWS availability zone. Failover wouldn't be completely clean/automatic, but we could lose either node with zero data loss, and would have a very short path to promoting the remaining node as a full master.

secure is now running repositories in fully redundant multi-master mode. This appears to be working, although it has been live for about 20 minutes and survived about three pushes so far so I'm not yet brimming with confidence about it.

This got some progress over the weekend -- it dovetailed a bit with T4292, and I wanted to let the Phacility cluster sit on the new availability stuff for a little while. Upshot:

Yes, Ubuntu is very popular. We use Ubuntu ourselves. This very server is running Ubuntu.

@CodeMouse92, I'm specifically curious about the claim I quoted: that Ubuntu 16.04 is a major platform for Phabricator hosts.

Why not collapsing the diff in this case?

I'm merging this into T10691 under the assumption that the real root problem is the one described there (your users want to treat git push as "save a copy", not "publish").

There's an inline comment, visible in the left margin of the left-hand diff. You previously collapsed it.

Maybe see also T3277. But it sounds like there's no actual problem here that isn't solved by running git branch -D slightly more often, and the root problem is a minor convenience issue, not a workflow breakdown? Everything works fine, you just don't want extra branches because you have to spend a few extra seconds cleaning them up later?

Why does the workflow break down?

Broadly, I lean toward this policy going forward:

At least for now, maybe I'll remove the setup issue to avoid confusion and just note this in the changelog instead. This is much more likely to be overlooked, but vendors other than Apple seem to have generally taken care of this and using git --version to test for the presence of the vulnerability isn't really meaningful.

safe to ignore if you've updated to the latest version even though it's a lower version number

In other cases (like with Shellshock) we can just test for the vulnerability to see if a binary is vulnerable. Ideally, we'd just perform this test to figure out if you need to upgrade, but I don't think a reasonable test case exists here because we need to create a 2GB pathname and probably can not do that in a reasonable amount of time.

what do you think about supporting a mode that always uses the client (browser) timezone by default without any manual action taken by the user?

Ubuntu 16.04 ... is a major platform for Phabricator hosts

T4752 is the detail on that.

Try that?

I think the sequence of action is:

I'm less sure about adding a warning to arc.

I've updated all Phacility cluster hosts which run any git operations (secure*, sbuild*, saux*, repo*) to 2.8.1.

Sorry everyone -- we don't actually read or write this table yet so I didn't add the schema, but the fact that bin/storage adjust would complain slipped my mind. D15744 will fix it and make sure bin/storage adjust is run as part of the test suite.

This is not a demo or test install. Please don't make a mess! You can launch a demo install on Phacility if you want to poke around and try things out.

I think this has come up a couple of times in the past, let me see if I can dig it up.

oh lovely, haha

Kicking this to the daemons should be like 20 lines of code, but we probably also need to flag the file as "queued for deletion" in the UI in the meantime and prevent you from interacting with it, which touches a few other interfaces, so this isn't completely trivial.

Just some cleanup today. New daemon console now shows which hosts daemons are running on:

Cool. Yeah, that all sounds good to me.

(If the current page isn't a Phriction page, I guess just don't mark the thing up?)

That seems reasonable to me. I like using ./ to opt in to this and not making it the default.

From IRC, this may be an issue with older ws (0.7.1) except that I also have 0.7.1 locally. But we should possibly upgrade / recommend upgrading / something like that.

I also tried swapping the ".key" and ".crt" but that gave me the same error as using a bogus file.

Other stuff I tried:

I can't immediately reproduce this...

A terrible workaround is to reload the page before editing.

FWIW, I briefly attempted to fix this while fixing T9348 and gave up.