- User Since
- Oct 16 2012, 9:30 PM (483 w, 36 m)
Jan 23 2018
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.").
Jan 18 2018
Among other advanced capabilities, PHP instructions execute too slowly to allow a runtime program to distinguish between L1 cache access and main memory access.
Sep 29 2017
I wonder if an "Owns $n Changed Paths" note on currently-relevant packages would be useful, or just distracting.
Sep 26 2017
Jul 13 2017
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.
Jun 19 2017
Much nicer! Thank you!
Jun 17 2017
Jun 14 2017
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.
May 19 2017
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.)
Mar 23 2017
Mar 17 2017
Mar 9 2017
Mar 8 2017
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).
Jan 10 2017
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.
May 21 2016
Dec 4 2015
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?