Restart Apache or PHP-FPM, according to the upgrade guide:

That isn't a great solution - it should be possible to set a max ram used, rather than max percent free

Shouldn't we do something similar by default?

In T8885#126858, @chad wrote:

Also, #phui is the best tag for these, which is "Phabricator UI". Maybe a good way to think about it is #design is pre-commit, #phui is post-commit. :)

Yeah that's true. Good point.

This is the dialog you had trouble with, right?

Then we'd need serious + non-serious locales in every language.

Just to make sure, this is the dialog you confirmed your way through by accident?

Shouldn't we do something similar by default?

I found it interesting that S3 got interpreted as remarkup. I wonder if we should blacklist it from being matched similar to Q1, etc.

I'll try to make this more clear after T8726.

Note that in this case and in the T8863 case, mail recipients must now be able to see objects (e.g., revisions and repositories) to receive email about them. It's possible that that's the source of this issue.

I can't reproduce this. Here's a rule I wrote:

I think this scenario would be better handled with a "Skip" or "Pass" build step than treating disabled plans as automatic passes. That behavior seems very unintuitive to me.

We already have such a mechanism.

You can click "Edit Project" to figure out what the policy is (it will either show you or tell you). This request doesn't really describe a problem.

Use --autoscale-reserve to prevent them from autoscaling past some amount of memory. For example, this will prevent autoscaling if less than 25% of RAM is free:

This report doesn't have enough information for us to reproduce the issue. See the documentation here:

I don't think our users would want to update Arcanist as often as I am updating Phabricator.

Another option would be to allow a minimum version to be specified server-side. As in, Phabricator reports a minimum version commit hash which is either maintained in the code itself or overriden by admins.

Also, 99% of the time when people ask me for help with Arcanist its just a matter of running arc upgrade.

Interesting idea. Composer gives some sort of warning if it is more than 30 days old... Maybe something similar would be useful for Arcanist.

This is interesting. We had an abandoned diff which got closed by ./bin/repository reparse. If I click on "Explain Why" then it says We didn't find a "Differential Revision" field in the commit message. That doesn't really make sense to me, is this a bug?

This happened again today. I ran for REPO in $(./bin/repository list); do ./bin/repository reparse --message $REPO; done and a whole lot of badness ensued.

Why is this passing instead of failing?

Use arc which to understand what arc is doing and why.

Currently, these results are essentially never useful to anyone, so I don't think the proposed solution (adding difficult-to-discovery complexity to the typeahead) is very good. Instead, we should improve the quality of the search results. For example, only indexing top-level atoms (in PHP, classes and functions). I believe we already have the concept of "top-level" in Diviner.

Why are they failing?

(I believe) get a warning on the command-line if you try to land when tests are failing/not yet reported.

This would discourage people from landing in the situation where a diff has passed CR but hasn't passed tests.

T8644 also discusses writing a "recipe book" for Herald, since there are a lot of things like this which it's powerful enough to do but where the pathway isn't necessarily obvious.

Oh, I suppose there's actually no way to specify "Administrators", per se, right now. We could maybe add one after T8726 wraps up.

its information content is 0.

Can you use a Herald rule like this?

Do you still happen to have the original error message? That was unexpected, and the migration specifically accounted for the case of email collisions and I recall testing that case locally in detail, so I'm curious what I missed. The expected behavior is that that list wouldn't migrate (and would emit a message), but other lists would:

I can write a lock log for this but it's going to add a huge amount of complexity and basically amount to implementing locks ourselves from scratch. However, I don't see any other way forward.

Locally, edge destruction works correctly. Here's a complete log:

Can you also enumerate exactly what problems you have with bin/remove destroy on tasks at HEAD? The expectation is that all these relationships are destroyed:

This is almost certainly fixed by outstanding changes to Herald which are awaiting review. See also T8822.

We don't plan to restore actAsUser in any form to the upstream, since it violates policies and can not be made safe (in the sense of not-policy-violating).

T8833 is also "arc land should restore state after a failure".

It is currently intentional that arc land does not restore state after a push failure.

Yeah, I think we're likely to remove this. It generally needs a lot of effort to modernize even if we're going to keep it.

Try this: