If you run those commands on their own, they're also slow? Even just this?

I can't reproduce this. Here's what I did:

Yeah, let me dig into that a bit and come up with some options. I have to go look at what the skin code is doing.

I don't think it costs us very much to keep it around, and it does make some stuff nicer/easier. For example, we'd have no way to link to the live blog or live post if we don't know what domain it's on, and I like checking the live post after publishing something.

Some thoughts from banging on this, not sure how much you want to deal with:

I'll see if I can come up with a reproduction case.

It would be helpful to understand how to reproduce this. Specifically, I think what's happening is something like this:

I'm just going to close this, I can dig it up later if I want to reference it.

This is basically all reasonable but entangled with the giant mess in T5791 and T9161.

Broadly, to set expectations, this is a very low priority for the upstream and neither of us really have any familiarity with Elasticsearch, so I don't expect to move this forward for a long time.

We don't currently support ElasticSearch 2.0. I'm collecting issues we've seen with it in T9893.

As an alternative, I'd like to consider dropping upstream support for ElasticSearch entirely. We originally implemented it because Facebook wanted it and the project was more willing to implement and maintain things. However:

@ru31337, that issue isn't related to this one and isn't "wontfix". Please see Contributing Bug Reports for instructions on how to report bugs. Choosing an existing similar task, changing it to "wontfix" and dumping your issue into it won't get it fixed.

I don't think telling users that their filenames must match a complicated regexp and expecting them to figure it out is a reasonable behavior for a linter to have. I think I'm fairly comfortable with regular expressions and not confident I could figure out what the message meant quickly, and I know at least some engineers just don't have regexp literacy as part of their toolset.

I suppose the "version number" I propose is a little tricky, because it won't be incremented if a user edits a comment -- this does not apply a new transaction. We could use a <MAX(transactionID), MAX(commentID)> version instead to catch edits.

Ah! That could definitely explain it.

See also T9515 and T7639 for "choose some other users to trust, if you lose your phone they can vote to strip your MFA".

This was an intentional change in response to requests by other users in T4333 and elsewhere.

See also T9640 for tracking PHP7 compatibility.

There isn't really one, all the applications that do it right are doing comments, and you can't do the same thing they're doing very easily. Audit does something but it's a mess. It should really just get restructured, I think.

I've marked D14637 as fixing this.

still won't get cleaned up and instead Drydock will just fail to allocate.

So you have a machine full of unused working copies, and Drydock is failing every build instead of reusing them?

When this happens, there'll be hundreds of builds all running at the same time, which can result in hundreds of working copies for the same repository.

I'm concerned that it's difficult to give users a descriptive error message if the pattern is an arbitrary regular expression. What does your patch do when a filename fails a custom regular expression? Specifically, how does it help the user fix their filename?

I don't know how to reproduce the behavior this report describes. See Contributing Bug Reports.

I can't reproduce this. Here's what I did:

Aaah! That makes sense.

I'm not 100% sure it actually works, but you'd just do this:

I believe if you include a transaction which sets the CCs to the current CCs, it is guaranteed to run after any personal rules and will entirely undo the effects of any sneaky rules anyone might write.

We also probably need to implement Phabricator Credits before we can add ᵐᶦᶜʳᵒᵖᵃʸᵐᵉᶰᵗˢ because otherwise we'll just be paying Stripe for the privilege of having ᵐᶦᶜʳᵒᵖᵃʸᵐᵉᶰᵗˢ.

My major concern with pursuing that (or, say, "$1 to file a task") is that user expectations will be like billion times higher if something costs $0.25 than if it's free.

I think that'll fix it, let us know if you're still seeing issues? Thanks for the report!

This is from D14622, probably just a missed grep (likely because the method name is spelled QuickSand instead of Quicksand at this callsite).

Broadly, we're in no rush to get rid of these events -- definitely no need to panic. I just wanted to push things in the right direction after T9851 was filed, which originally asked for the scope of these events to be substantially expanded.

My recollection, at least, is that Herald wasn't originally suitable because of T6367. Prior to that task, an "attacker" could write a rule like this:

See prior discussion in T5021 / D9270.

What are you doing which can't be covered by Herald?

I can't reproduce this. Here's what I did:

That's expected if you've written an "every time" rule.

so I end up with lots of copies of the same thing

Which instructions were you looking at which you found confusing? Can you point me at the document? (Or was it the setup warning itself?)