Yep, works now. Thanks

Thanks, try HEAD?

D15934? looks like it introduced "suffixes" for reviewers.

I'm not sure if this change is correct, but it seems to fix the issue for me: https://secure.phabricator.com/differential/diff/38381/

arc diff is not expected to upload coverage information without additional configuration.

I think the output format from differential.parsecommitmessage has changed:

Whatever's generating your coverage information (A unit-test engine) needs to provide file names relative to the root of the repository; The snippet you have is showing the filenames are absolute.

Oh, this is probably the correct error log:

Server-side, I have the following commits deployed:

Updated version information:

You're also two months out of date, see Contributing Bug Reports.

Please include reproduction steps when filing a bug report. See Providing Reproduction Steps for help.

Blocking reviewers can now be added, edited and removed via the web UI with the blocking(...) function. For example, entering blocking(epriestley) into the "Reviewers" typeahead will add epriestley as a blocking reviewer. You can use this to upgrade reviewers to blocking or downgrade blocking reviewers to non-blocking.

Sorry, maybe I didn't explain that very well. I already understand you want the data, I don't understand why you want that data. The upstream isn't going to get into database nitty gritty without a Phacility Consulting contract ($1500 / hr if you're interested), but perhaps if you let us understand what problem you're trying to solve, we can give you pointers as to the best approach (APIs?)

Hello chad,

Might be quicker to simply tell us what you are attempting to do.

Sounds good (including your last comment). I think that from our perspective, we're it seems likely that we'll end up realizing a few problematic edge cases or details once we start integrating fully and it's probably best to wait until then than to try to gain perfect confidence ahead of time. The work done so far and what you outline in your last comment seems sufficient to start doing the integration work and we can surface issues as they arise.

I've consolidated the general state of the world in Audit in T10978. I think we'll run into some of that eventually but I'm not sure how much is important vs nice-to-have, so my general plan here is to just scratch the surface for now:

See T3498.

When we can identify the author, I'm just going to make auditing stop trigger audits by any packages they own, even if there was no review.

I would like to also suggest to add option to ignore whitespace changes when comparing different version in the audit page ? Differential allow it, but audit does not currently. Thanks.

right now, out workaround is to use herald to create the audio, and use "author is not any of " the single person group. a better explaination of the situation was written in my T6701.

Presuming this was fixed some time in the last four years, barring any new reports. The code has code to do this, at a minimum.

I think this was effectively resolved by T8004 / D13923.

At HEAD (after D15929), bucketing is now more considerate of individual reviewer status and cases in T5217 should be handled in line with user expectation.

I'm going to merge this into T10967. Although it would be possible to fix in advance of that, I think it is unlikely that we'll pursue the changes outside of the larger infrastructure changes discussed there.

When you deleted the user, did you see this prompt?

At HEAD, I can't reproduce this:

I think this is covered by T8612, unless you can produce a small change which requires a disproportionately large amount of time to render. It is expected that large changes will take a proportionately large amount of time to render.

No clue how to reproduce this and haven't seen anything similar in the ~year since. File a new one if you have some idea how to repro it.

But a root owner's accept will still count for the sub-package, provided dominion is weak?

The driving use case for this fell through, and I no longer plan to pursue it.

Ah, thanks for following up. That's interesting and a little perplexing, although just fixing this stuff via T10967 is probably still the best way forward. I'll keep an eye out for similar reports, though. That does tend to make me think it might be a real race.

Oh, my apology for not replying on your previous comment, somehow the notification slipped through and I'm not a very regular visitor of this Phabricator instance.

In T10939#175619, @epriestley wrote:

Just to make sure I'm understanding correctly:

I'm going to merge this into T10967, since after digging around in the code a bit recently it seems unlikely that we'll pursue the infrastructure changes required to fix this outside of the context of that larger infrastructure change.

I expect that when a package is defined with Auditable enabled, each commit that affect the package will trigger an Audit rule.

(I'll restore viewer(), it's just not a one line change.)

In T10939#175557, @epriestley wrote:

Yes, since it would really mean exact(current-viewer) without additional work. Are you using it for something (dashboards?)

Just to make sure I'm understanding correctly:

I can only reproduce this if (3) is changing "Visible To", exactly: i.e., same file policy scrambling issue as T10778. Should have the same fix.

Ref T10778

In T10939#175518, @epriestley wrote:

• "Soft Accept" / "Unblock" action ("TBR").

Likely the same as T6815 since I think they're the same code.