Why are users updating revisions if they don't want reviewers to look at the changes yet?

I'd like to find a solution other than the proposed behavior:

• It requires users to go push some "Ready for Review" button after they update, which adds an extra step in what I believe to be the overwhelmingly common case (for example, 100% of my own updates are ready for review). This is more complex, more time consuming, and less obvious. My expectation is that about 99% of diff updates happen from the CLI, so this would add nontrivial overhead (load web UI, go make changes) and/or complexity (magic in update messages).
• Keeping the revision out of the "Blocking Others" bucket is only part of the state effect. For example, it doesn't suppress mail or notifications. If these updates aren't ready for review, it seems like they shouldn't be getting made at all.

Are these updates serving some purpose? Why are users making them? From your description, it seems like they provide no value to anyone.

In particular, how does updating a revision help someone try to fix a problem?

Are they trying to run unit tests or lint, and there's no way to run them locally, and/or they aren't familiar with "arc unit" and "arc lint"? Or are some tests or build steps only available by updating revisions? If the behavior is generally rooted in some issue in this vein, I think we should seek to address this issue, as it seems like the root cause. In a "normal" configuration, all tests and other pre-review steps should be available to users locally.

Are they trying to get past security review, and your security review is implemented as a million regexps in Herald rules instead of proper linters?

@epriestley - hmm, good points. I think it's mostly due to wanting to run tests. I'll monitor this and let you know if there's any other significant sources.

• arc test xyz runs one suite of tests (xyz). Also, for some reason it barfs when we have changes that have binary files, though perhaps that's our fault and nothing to do with Phab.
• arc test only runs one specific suite of tests. Again, perhaps thats our problem
• arc diff will run all relevant suite of tests (the suite of tests changes pretty regularly)

So perhaps the issue is just specific to us:

1. Why arc test barfs on changes with binary files
2. Getting arc test to use whatever method arc diff does for deciding which test suites to run

Just to clarify, you really mean arc test and that isn't a typo of arc unit?

arc test isn't even a command that exists the upstream, so any issues with it are definitely on your end.

Getting arc test to use whatever method arc diff does for deciding which test suites to run

(You can run the tests that arc diff would run by running arc unit, which is the upstream way to run unit tests.)

@epriestley - Whoa, that's awesome... sorry to bother you with this!