The "role" stuff is mostly just practical/technical: we have to do about 95% of the same work whether we end up with multiple configurable sets of defaults or a single set of defaults.

We should probably improve this behavior at some point, but it isn't entirely trivial, I'll likely do concurrently with T9132 anyway, and the current behavior is a little rough but doesn't seem too bad (it's inconsistent and needlessly indirect, but not technically incorrect).

D14097 reverts this because it felt really bad in production, and generally not very promising as a direction we could iterate on and make successful.

For whatever it's worth, here are the comparable (14-day) numbers from this install with the more modern script:

How about we:

D14096 has some screenshots of this and I've pushed it to this server. It may get some design followup but feels relatively reasonable to me in its current form.

T9393 discusses the "Blackbox" extension. To summarize:

Cool, that sounds reasonable. Broadly:

Here's a case where the result feels OK, especially if I'm a new user:

On real data, this feels very bloated to me for tasks, at least:

Can you just disable the extension for Phabricator's copy of the repository?

The erroneous revision is because when hg log is invoked with --debug, it prints arbitrary messages to stdout which we can not distinguish from log output.

Why are you interested in running this extension?

This doesn't feel completely solid to us yet so we're going to try it out for a bit and see if there are further adjustments to make. We're interested in feedback on this version of the feature if anyone has a particularly positive or negative experience with it. I'll push it to this install shortly so it's available to play around with.

See that diff for some details, here's what it looks like currently:

D14095 is a rough pass at this. I'm summarizing (showing the first ~paragraph of content) rather than showing contextual content around body search results. This is easier and maybe-better, given that our search results are more highly structured than webpages? I'm not sure if this holds up in practice.

This should be resolved by D14092. Thanks for the fix!

@berenm suggests what is likely a simpler fix here:

See also T7004, although I'm generally not hopeful about being able to build a version of that which feels like it works well.

What if we do this?

I get some odd results locally, in MySQL too, although I have a very small table on my laptop (~1100 rows):

No.

The fact that it's not using the key at all explains why the GC was slow for you and why removing the ORDER BY improved performance, at least, but it seems like it should be able to use the key to execute this query efficiently, and appears to do so in MySQL (we don't have as much data as you do, but I don't recall the GC having any issues when we pushed this change here, and other large installs haven't reported issues but I'd expect them to if the GC was not able to use the key).

I'm tentatively inclined to think that this is a bug in Percona, since:

Yuck. Can you come up with any query where it uses the key? What if we do something really dumb like this to try to trick it?

Out of curiosity, what's the query plan for this (DESC instead of ASC)?

Hmm, that's surprising. At least on our dataset, I get a worse-looking query plan without the ORDER BY:

We do not currently support git notes, and I had never heard of it before this task.

Yes, this looks consistent with the GC and publisher deadlocking.

That just looks like a bug that's only tangentially related, I think Audit and Countdown are both trying to receive mail at C... addresses.

Create a dashboard panel with the query, then embed it with {W...}.

I don't plan to pursue this. We'll offer JS access to the OAuth API instead (see T7303).

Maybe renaming "Arcanist Client Results to "arc lint + arc unit" would be clear enough? It sounds like this workflow is generally fine, users are just not making the connection between "Arcanist Client Results" and the "arc" client?

I don't see an especially clear way forward here:

This is not blocked, although it's a moderate amount of work (4-6 hours?) and not adjacent to other work.

This is 1-2 hours of work and can be slipped in somewhere if approved.

We can look at this as part of the next Phriction iteration, although other changes likely impact the eventual design here.

I don't anticipate implementing these in the upstream. Remarkup is extensible enough that these could be implemented as extensions.

See above.

Did D12730 resolve this?

This exist and has at least been minimally useful in making it easier to improve package definitions, if nothing else.

This is the same as T1849 but I'm just going to merge that here since this one is sort of more complete, even though T1849 has a great screenshot.

At HEAD, I get this:

We've never seen other reports of this, but it's <1 hour to fix. We can weave it in somewhere if approved.

Some discussion in T9367.