[RFC] Deprecate pre-commit email code reviews in favor of Phabricator

Runtimes C++
#1

This is a revision of the previous RFC[1]. This RFC limits the scope to pre-commit reviews only.

Statement:

Our current code review policy states[2]:

“Code reviews are conducted, in order of preference, on our web-based code-review tool (see Code Reviews with Phabricator), by email on the relevant project’s commit mailing list, on the project’s development list, or on the bug tracker.”

This proposal is to limit pre-commit code reviews only to Phabricator. This would apply to all projects in the LLVM monorepo. With the change in effect, the amended policy would read:

“Pre-commit code reviews are conducted on our web-based code-review tool (see Code Reviews with Phabricator). Post-commit reviews are conducted, in order of preference, on Phabricator, by email on the relevant project’s commit mailing list, on the project’s development list, or on the bug tracker.”

Current situation:

#2

Seems reasonable to me. I’m not strongly in favor, but since I was strongly opposed to the previous proposal, a “don’t object” seemed reasonable to share.

Philip

#3

This is a revision of the previous RFC[1]. This RFC limits the scope to pre-commit reviews only.

Statement:

Our current code review policy states[2]:

“Code reviews are conducted, in order of preference, on our web-based code-review tool (see Code Reviews with Phabricator), by email on the relevant project’s commit mailing list, on the project’s development list, or on the bug tracker.”

This proposal is to limit pre-commit code reviews only to Phabricator. This would apply to all projects in the LLVM monorepo. With the change in effect, the amended policy would read:

“Pre-commit code reviews are conducted on our web-based code-review tool (see Code Reviews with Phabricator).

I’m with you here ^, this seems to document/formalize existing practice - though does this accurately reflect all the projects in the mororepo? I get the impression that mlir, maybe flang, etc might be doing reviews differently?

Post-commit reviews are conducted, in order of preference, on Phabricator,

This still seems like a change in practice that I’m not in favor of, personally - due to the current divergence between email and phab review feedback. Yes, this would be one way to unify it - but I’m not sure it’s necessarily the best one.

I’d suggest leaving this to a separate proposal so as not to complicate/muddy the waters of the formalization of pre-commit review practice.

#4

Post-commit reviews are conducted, in order of preference, on Phabricator,

This still seems like a change in practice that I’m not in favor of, personally - due to the current divergence between email and phab review feedback. Yes, this would be one way to unify it - but I’m not sure it’s necessarily the best one.

I’d suggest leaving this to a separate proposal so as not to complicate/muddy the waters of the formalization of pre-commit review practice.

I simply broke up the existing sentence from the documentation into two parts, one about pre-commit reviews and the other about all other code reviews (which are basically the post-commit reviews, although I’m open to corrections here). The first part was modified to reflect the proposed change, the second part was left unchanged. In this RFC I only want to change the part of the documentation that pertains specifically to pre-commit code reviews. If the wording I used creates confusion, what would you suggest instead?

#5

+1, makes sense to me.

-Chris

#6

Post-commit reviews are conducted, in order of preference, on Phabricator,

This still seems like a change in practice that I’m not in favor of, personally - due to the current divergence between email and phab review feedback. Yes, this would be one way to unify it - but I’m not sure it’s necessarily the best one.

I’d suggest leaving this to a separate proposal so as not to complicate/muddy the waters of the formalization of pre-commit review practice.

I simply broke up the existing sentence from the documentation into two parts, one about pre-commit reviews and the other about all other code reviews (which are basically the post-commit reviews, although I’m open to corrections here). The first part was modified to reflect the proposed change, the second part was left unchanged.

I think the issue is that the original phrasing was probably only intended to describe the preference for pre-commit review. (I think statements about post-commit review could reasonably read to be only those that say “post-commit review”, in this ( https://llvm.org/docs/CodeReview.html#can-code-be-reviewed-after-it-is-committed ) section.

So I think (at least in terms of how to read it in a way that matches existing practice) the original wording amounted to something like this:

… “post-commit review can use any of the tools listed below” …
… "pre-commit review is done in this order of phab, email, etc… "

ie: the post-commit review didn’t have the same order of preference as pre-commit review.

I’d probably pull out the post-commit review-specific wording back up to where post-commit review is discussed, and leave the rest of this to talk about pre-commit review (most of this document discussing unqualified “review” seems predominantly to be talking about “pre-commit review” except the part that talks about “post commit review”).

Probably move the “on our web-based code-review tool (see Code Reviews with Phabricator), by email on the relevant project’s commit mailing list, on the project’s development list, or on the bug tracker.” (without the “in order of preference”) up to the “post-commit review” section, instead of referencing a version of it here.

#7

Code review guidelines patch is available for review: https://reviews.llvm.org/D103811.