Recently smtp-relay.gmail.com stopped accepting email from our Phabricator instance because it turns out Phabricator was sending HELO localhost.localdomain instead of HELO smtp-relay.gmail.com when doing the SMTP connection.

There is a Migrate from Google+ Sign-In howto for web apps.

The error truncating behavior affects also Diffusion > R > Status, where only part of the stderr is shown, making it impossible to debug the problem without hacking Phabricator:

ab@phabricator-1-vm:/opt/bitnami$ diff apps/phabricator/libphutil/src/future/exec/CommandException.php.original apps/phabricator/libphutil/src/future/exec/CommandException.php
59c59
<     $limit = 1000;
---
>     $limit = 1000000000;

Arcanist hides part of the stderr to prevent console spam. But what problem does this fix exactly? How is it a problem that 5GB of output are printed to stderr? The way I see it, if the tool called by arc prints a lot of info to stderr, it should be assumed it is printed for a good reason, be it 1KB or 5PB.

The same as what you do with any tool which produces 5GB of output: wonder what happened, then try again and redirect the output to a file and deal with it. Currently the user has to run manually the steps printed when using --trace, and then they will get to that 5GB output anyway.

We need to check programmatically whether all the reviewers approved. Any suggestion how this could be done?

Could you reopen and set it as feature request?

Commenting here since you merged T12429. I find surprising you put Arcanist in the same bucket as Phabricator. I think you don't even have to do all the work to make Arcanist users happy. I might be wrong, but I think there will be people adding support for Arcanist to their favorite package manager (I'm ignoring Windows), if only they'd have tags or marked releases to work with?

Ok, thanks for the explanation!

As you described, the model would be very complex considering a task can be in more than one subprojects, or a milestone. Why is it needed to have separate columns for subprojects in a parent project's workboard?

Why is the list of diffs in a task page ordered by creation time?

In T9987#155481, @epriestley wrote:

We have not seen any evidence that installs which do not use git-phab experience this problem,

I think there is a misunderstanding. The problem is not caused by git-phab, it only becomes more visible with git-phab.

Could you please reconsider this task considering what I said in the previous comment?

We use git-phab, a tool which creates a task per branch and keeps the commits in the branch and the diffs of the task in sync. https://phabricator.freedesktop.org/diffusion/GITPHAB/ What this means is that it allows us to change the order of the diffs more easily, so in our case it will happen more often!

When the reviewer looks at the task to review the diffs, he needs to start somewhere and end somewhere. This is where the diffs list help: the reviewer will start at the top and finish at the bottom. Currently the diffs are ordered by creation time. Normally this works ok because the newer diffs depend on the older diffs. But if a newer diff is made a dependency of an older diff, the order of the list is not relevant.

In T9986#149260, @chad wrote:

Afterwards I clicked on Create Task and it worked, it did not give me any other error.

Where, specifically. "Create Task" is a permission-locked form on this install.

Sorry, those two pages are ridiculously long, I won't read them.

Not sure what you mean. Afterwards I clicked on Create Task and it worked, it did not give me any other error.

In T9986#149208, @joshuaspence wrote:

Can you provide steps on how to reproduce this bug, it's not clear from your report. See Contributing Bug Reports.

For example here D506 should be between D560 and D561, not at the top:
https://phabricator.freedesktop.org/T3491