[docs] Set Phabricator as the tool for pre-commit code reviews

[kparzysz]

Summary

This is a follow-up to the discussions about deprecating email code reviews in favor of Phabricator:
https://lists.llvm.org/pipermail/llvm-dev/2021-May/150344.html
https://lists.llvm.org/pipermail/llvm-dev/2021-May/150619.html
It includes updated wording suggested by David Blaikie.

I did not move any information to different sections because that would change the structure of the document: I wanted to keep the information about tools used for reviews in the same section where it was originally located.

[dblaikie]

This looks about right to me - probably follow-up on the email threads to mention this has been sent for review/link to this review?

[dblaikie]

Sounds good

[beanz]

So, I realize I probably should have mentioned this earlier on the llvm-dev thread, but is this really a change we should be making the week after Phabricator officially became an unsupported project:

https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/

I feel like in practice we use Phabricator and not really pre-commit email reviews, so this might just be formalizing the practice, but Phabricator not being officially maintained means that we'll likely need to move off it at some point, so this policy change would likely be short lived.

[dblaikie]

In D103811#2810887, @beanz wrote:

So, I realize I probably should have mentioned this earlier on the llvm-dev thread, but is this really a change we should be making the week after Phabricator officially became an unsupported project:

https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/

I feel like in practice we use Phabricator and not really pre-commit email reviews, so this might just be formalizing the practice, but Phabricator not being officially maintained means that we'll likely need to move off it at some point, so this policy change would likely be short lived.

Good to know (+@mehdi_amini) - but given this is a small/simple textual change and codifies existing practice, I'm still good with this change.

But I agree this does mean we need to be re-evaluating our tooling around code reviews, and might help push things in the direction of moving to pull requests, for instance.

[mehdi_amini]

The commercial entity behind Phab is dropping development of new features but they said they'll keep the maintenance for the foreseeable future I believe. Also there is a community currently organizing to fork the project and continue the development: https://docs.google.com/document/d/1YxQ_JGdhWYPSdoaI_m1TLzwbGLZdtOD7ux2SVL263Ow/edit

Also, we have been upgrading our instance every ~2years. It is overall quite stable so we won't be under any "urgency" any time soon.

[kuhnel]

+1 on David and Mehdi

If we move to another code review tool, we would just s/Phabricator/the new tool/g and the general workflow would hopefully stay the same.

[lattner]

nice, thank you!

llvm/docs/CodeReview.rst

 That having been said, if a substantial period of time has passed since the
 original change was committed, it may be better to create a new patch to
 address the issues than comment on the original commit. The original patch
 author, for example, might no longer be an active contributor to the project.
 
 What Tools Are Used for Code Review?
 ------------------------------------
 
-Code reviews are conducted, in order of preference, on our web-based
-code-review tool (see :doc:`Phabricator`), by email on the relevant project's
-commit mailing list, on the project's development list, or on the bug tracker.
+Pre-commit code reviews are conducted on our web-based code-review tool (see
+:doc:`Phabricator`). Post-commit reviews can be done on Phabricator, by email
+on the relevant project's commit mailing list, on the project's development
+list, or on the bug tracker.
 
 When Is an RFC Required?
 ------------------------
 
 Some changes are too significant for just a code review. Changes that should
 change the LLVM Language Reference (e.g., adding new target-independent
 intrinsics), adding language extensions in Clang, and so on, require an RFC
 (Request for Comment) email on the project's ``*-dev`` mailing list first. For