Sorry to hear that and hope everything is OK with you @epriestley.
I spent many hours learning from this high-quality code base.
Best of luck in whatever you do in the future.

Roger that. I don't expect support for it and it's quite minor, I merely thought it slipped through. I will let it be, and will use https://discourse.phabricator-community.org/c/bug in the future.

@chad, bringing this up as it still persists after today's upgrade. Apologies in advance if replying to a bug is not the preferred way to resurface it.

Although the new graph display has the branch-like display at the left, that column is removed from the task titles (2 columns away) - which aren't indented to clearly show the parent-child relationship.

@OCram I've been using it in production for months, it works well enough for our needs, including in the current codebase. It just displays child tasks in a tree-like manner, doesn't change anything.

This indeed looks fresh and cleaner, good job.

In my case when attempting to generate symbols (per https://secure.phabricator.com/book/phabricator/article/diffusion_symbols/ ), this error was fixed by running make install in /usr/local/phabricator/libphutil/support/xhpast

To add to this, viewing a Task shows "Projects" whereas editing it shows "Tags". This caused confusion to one of my users, who couldn't find where to update the Projects while editing a task.

*nod* I found that task and used it to clean my arcpatch branches. If I may make a suggestion, could arc patch try to be clever about it and overwrite arcpatch-D69 only if there are no local modifications, and/or after confirming with the user?

Excited about this too!

I just realized after testing a few versions that the "Auditors: <username>" in the commit message needs to have 1 empty line before it to be triggered. Probably some parsing issue.

After a few months of using P1094, we have found it invaluable in getting an overview of big and deep tasks. It is sufficient for our needs, we're happy with it continuing to work locally.

$edge_type = PhabricatorEdgeConfig::TYPE_TASK_DEPENDS_ON_TASK;
This won't work in current code, since December 2014

After thinking a litle more about T9183, the usability issue I'm seeing as our usage of Phabricator grows is *finding* the object / Project in the JS policy dropdown, to which I want to make the edited task visible. As the Projects list grows long, this action requires scrolling the entire page and results in a jerked jump back to top after selecting a Project. The natural sorting that I suggested there would only alleviate this slightly.

I recreated the error:

Unfortunately no, it fell off the scrollback buffer. It was attempting to create database phabricator_spaces, and the mysql user it was using per the configuration didn't have access to do that.

In T8549#124461, @fanis wrote:

@chad I hadn't upgraded, partly due to this. I'll do that soon and get back to you. Appreciate the quick responses.

@chad I hadn't upgraded, partly due to this. I'll do that soon and get back to you. Appreciate the quick responses.

In T8549#124258, @chad wrote:

We definitely don't test Phabricator out to 150% size. Are people using this on a day to day basis? Is this a regression?

We also include natively a larger font in Display > Accessibility.

In T8549#121394, @20after4 wrote:

When I scale the text size up a bit, I get a weird left margin of blank space next to the page content:

This happens in both Firefox and Chrome on ubuntu. It takes two steps of ctrl-plus in Firefox, but it takes 3 (150%) in Chrome.

Adding clear: left; to the #phabricator-standard-page-body element fixes it. Apparently something in the header (which is float:left) is slightly extending outside of the bounds of the header and pushing the page body over.

Edit: Sorry, didn't notice that @staticshock already posted the same issue. Hopefully this is still helpful as I am pretty sure that I have isolated the cause/solution. It wasn't at all obvious at first.