From reading the code, resigning (instead of accepting) probably also leaves the revision in "Needs Revision".

In T12896#228825, @jmeador wrote:

We"solved" the problem with a small python daemon that pings repository_statusmessage.epoch every minute and calculates the delta. When these deltas surpass Phabricator's max delta (21,600 sec) we page the oncall. For repositories that are mission critical, we use a smaller value. It obviously isn't a perfect solution, but it gets the job done and it's been extremely stable.

I've seen complaints about this on phabricator.wikimedia.org as well, so I can confirm that this is an issue.

O.O

In T12847#229548, @joshuaspence wrote:

AWS doesn't have a single device which can both listen for TCP on 22 (only ELB) and terminate SSL for websockets (only ALB).

That's not correct. We are routing our websocket traffic for Aphlict through an ELB that has been setup using SSL instead of TCP as the protocol. In Terraform, it looks like this:

It looks like the price difference is pretty large -- $45/month for a m4.large reserved instance vs $80/month for a m4.large dedicated -- plus ~$1,500/month/region for having at least one dedicated instance. It would be easy to start using dedicated hosts in the future, right? Just an issue of converting existing hosts if we run into issues?

We should also make a decision about whether or not we want to use "dedicated" AWS instances: https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/

Another correction, Puppet doesn't //need/ a dedicated server. You can run Puppet in a standalone (agent) mode, if you are willing to somehow get your Puppet manifests onto each host that you wish to provision.

In T12856#229564, @joshuaspence wrote:

In T12856#227621, @amckinley wrote:

Terraform Review
Pros:

• Written in Python, which everyone knows is superior to Ruby in every way

Huh? Terraform is written in Golang, not Python.

In T12856#227621, @amckinley wrote:

Terraform Review
Pros:

• Written in Python, which everyone knows is superior to Ruby in every way

A customer is hitting an issue where pushes to staging areas do not push LFS objects. I'd guess this is an LFS upstream problem based on a hazy recollection of events here.

FWIW, I am actively working on a Puppet module for Phabricator, see https://forge.puppet.com/joshuaspence/phabricator.

AWS doesn't have a single device which can both listen for TCP on 22 (only ELB) and terminate SSL for websockets (only ALB).

Also, have you tried looking around the git community? I was always under the impression that SSH should be faster than HTTPS cloning, or possibly using the same protocol.

What if they're on the page, is that notification annoying? I love click that little guy.

+1, we've also had a handful of users request this as a per-user preference.

Ahhh, ok, these were all in one place. Yeah it's hard to find. I wanted to turn off self-actions, but "Preference" link sends me to a place that doesn't have that link so it seemed a point of user confusion.

Erm, sorry Email Delivery.

I don't see an "Email Settings" panel, am I missing it or did you mean a different panel?

Or just have a subtask-array configurable, going with the inline approach mentioned above:

Also, it would be great if you can choose an optional "default subtask subtype" where you configure the subtypes. Something like this:

Solves things for my instances, cheers!

Does this also include the functionality to specify what subtype to be used when you click "Create subtask", or is this just the visual element?

Going to keep this Open and build out some proper blank states. This feel pretty janky.

I pushed a hotfix up at HEAD of master, let us know if you're still having problems. Thanks for the report!

Please provide reproduction instructions. There aren't enough details here.

Hm, this screenshot made me dig a bit into the whole thing, so here is what I've found:
First, my date format is different because of my settings:

• Default settings of this instance: F5042482, with date format: F5042480
• My default settings: F5042481 with my date format: F5042479

Why does your date format look different than ours? Is that a local modification or do we support this somewhere I'm not aware of.

Merging over so there is one thread on this topic. We're happy to reopen if you have new reproduction steps we can follow or if you can verify on a Phacility test instance.

I can't reproduce this (again)

Here's the proof: F5042439

<script>alert(xss)</script>

Thanks @chad for the doc.

FWIW, I don't think these are "pure" spam emails, as in, that they are 100% unwanted by everyone. Even if you cannot see the underlying diff, you've asked to be notified when work happens essentially on a task. I think it's difficult to have Phabricator assess whether this email is informative or not to each individual user who subscribed. To some who are waiting for the product, it's valuable, to you or others perhaps not at all. Client side filtering still seems like the correct workaround until T5791 (which is server side email filtering).

Hmm, what did you try for search, off hand, do you recall?

In T10745#229028, @chad wrote:

I'm not sure I follow what you're trying to tell us.

I'm not sure I follow what you're trying to tell us.

These types of e-mails are still being sent. Here's one from July 10, 2017:

T4411 discusses some similar issues, although it predates Spaces and focuses on subscribers rather than assignees.

You configure this per-project in the .arcconfig to set

{
...
"history.immutable" : "false"
...
}

I read arcanist's source (src/workflow/ArcanistWorkflow.php)

I made it! great.

I also checked these places according to man hgrc:

I made sure that there is no aliases in ~/.bashrc and ~/.profile. And there is no ~/.bash_aliases

No... at least, as far as I can make sure.

It doesn't even look like arcanist is using --merge argument -- the last command it tries before failing is hg checkout 'default'. Do you have an alias setup in .hgrc or something similar?

mercurial is 4.2.
I updated the question, but paste the log here too.

Gonna try the button and see if it sucks.

@epriestley I think "Clone" via a button -> dialog is like 20 minutes of work for me, and the dropdown 2-3 days of fighting javascript. Unsure which you prefer in the long run.