Wow, I didn't mean for my two cents' worth of snark to cause such a stir! I do buy the argument that Phabricator isn't impacted by Meltdown/Spectre ("At least today, Herald rules are insufficiently expressive to allow an attacker to encode a speculative execution cache timing side channel attack.").

Among other advanced capabilities, PHP instructions execute too slowly to allow a runtime program to distinguish between L1 cache access and main memory access.

I wonder if an "Owns $n Changed Paths" note on currently-relevant packages would be useful, or just distracting.

That sounds less surprising to me, in the sense that it's not an explicit reversal of having requested changes. I can imagine arguments in both directions for the resign case.

Much nicer! Thank you!

I'm not totally sure about how/why users are expecting the behavior in the third case.

When you put it that way, it does seem backwards.

We're interested in this option, since we find that users are often surprised by the existing behaviour. I think this would make sense as a per-package setting, rather than a global one.

Super! We'll report results when we've got it deployed.

I'm not 100% sure, but from reading the subpriority movement code, it seems like our bell-curve distribution is self-perpetuating--when a block of tasks are moved, most of the time the next task is still relatively close, so $delta is small. I think this might be resolved by a big one-time readjustment to distribute tasks evenly throughout the space. I don't have an intuition on whether this distribution will redevelop over time, or if it's an artifact from the time before D12166.

It looks like even after D12166, the subpriority-assignment logic doesn't do a great job of spreading our subpriorities. P2053 shows that very many of our tasks have subpriorities near 0 (in fact, the vast majority of our tasks; a separate query without the > 1 limit indicates that only about 4k tasks have subpriority neighborhoods of their very own.)

Cool, this would be great!

More generally: I think your decision to not try to migrate saved queries makes a lot of sense. In lieu of that, I'd like to cast a vote for more prominent mention in the changelog. It would be great just to see a note that some queries would break and some hints on identifying and replacing/repairing the broken ones.

I've hit the same problem that @cspeckmim ran into. As best I can tell, in the new system there's no way to quite replicate the behaviour of the old 'needs' or 'problem' audit queries. The closest attempts I've come up with so far are:

• query for Audit Status = Audit Required/Needs Verification and Responsible Users = viewer(). But that includes results where the user is the diff author, not auditor.
• query for Audit Status = Audit Required/Needs Verification and Auditors = viewer(). But that misses results where user is a member of a package or project auditor.

I think this would work if I could query for Auditors = viewer()/projects(viewer())/packages(viewer()), but it seems the functions aren't composable (at least in the UI).

Hurray, thank you!

Aha, of course. Thank you!!

I'd be happy just to have a good workaround, since I don't think we're particularly attached to these mostly-contentless rows. My ideas for possibilities so far are:

• Delete the offending differential_hunks rows manually. I worry that this might cause some inconsistency.
• bin/destroy the revisions containing the offending hunks. This seems a bit heavy-handed though.

I think we're going to work around this by changing our base config value to git:upstream, git:merge-base(origin/master) and decreeing that if you want to do this sort of dependent feature thing, you have to explicitly set child-feature's upstream to feature. arc feature does that automatically, so we might just encourage people to start using that.

pretty big rough edges for the workflows it intends to enable

What are these, specifically? Is this entire task moot?