D19366 adds a "View as Query" option to the dropdown on workboard columns. This will take you to the Maniphest query results page with a query that selects exactly what was shown in the column when you selected the item.

We can also get a "Something something won't allocate a terminal because something something pseudo-tty." warning without -q. I'm 100% confident this is the exact text of the error.

@epriestley where's the countdown for the unnamed league 6/1 ? :p

Yeah, this is a combination of a bulk editor bug (which lets you delete task titles) and legacy compatibility code for transaction title rendering (which treats null -> anything transactions as "created this thing.").

Oh, good, it's about time this task be created!

I think https://secure.phabricator.com/book/phabricator/article/remarkup/ needs update to include this.

I'm leaning toward:

Hmm, I can't reproduce the issue. Here's pre-comment:

• Source view rendering in Paste has a missing background color.

I think that's pretty much everything. There will be a little followup work in T10883 and maybe T13076 / T13120.

Everything here should pretty much work except:

Actually turns out that the work around isn't reliable - I still get that error occasionally (I'm using SSH)

In T9450#163090, @WTreutterer wrote:

The same problem occurred on my site with the latest Phabricator and the latest Mercurial 3.7.2 installed on both sides.

Interestingly, it can be cured setting a special development debug flag for in the Mercurial configuration file:
in /etc/mercurial/hgrc or in vcs-user's ${HOME}/.hgrc adding the following snippet

[devel]
bundle2.debug = true

caused a hg push to a hosted Phabricator repository to work without a problem. But do not ask me, why.

I think all the T13076 stuff is blocked on me for now unless you're feeling especially ambitious about trying to get bin/host download working on 2GB+ files (T12907 / D19011). That might be a bit of a mess of a task though since I think I have a lot of secret cURL knowledge from over the years that is only somewhat-documented in HTTPSFuture.

Oh, I'm happy to kick this down the road until we go through the Big Compaction. I just saw this task as a dependency for T13076, which is on this week's planning board and figured I'd tackle it. Is there a different task you think I should work on instead to move T13076 forward?

Backups should run continuously (starting 12 hours after the instance launches, then every 24 hours after that):

I'm going to go through the volumes type-by-type instead of host-by-host, starting with the backup volumes (because those should be fine to detach as long as the backup isn't running). It looks like backups run daily at 2300, so that should give me plenty of time.

Hmmm, then maybe the narrowest way to solve this is to just setup disk space alarms. That's a thing we'd want independent of how we eventually build the One True Logging System. The CloudWatch agent collects disk stats out of the box, and takes a list of mountpoints to track. Details here: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html

Before I can get rid of AlmanacDeviceTransaction::TYPE_INTERFACE, we have two meaningful callsites in rSERVICES and one unit test in rSAAS to clean up.

There's a bit of a mess with AlmanacInterface and AlmanacDevice. Currently, AlmanacInterface does not use transactions, and is edited purely as a side effect of INTERFACE transactions applying to AlmanacDevice. I'm going to change how this works so that AlmanacInterface is a normal transactional object and can use the same rules and infrastructure as everything else.