<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>All of the variations suggested seem reasonable to me. I minorly
prefer James' wording, but any of them are better than nothing. <br>
</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 11/18/19 7:53 AM, Finkel, Hal J.
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1006cb80-7911-ad09-6b09-2956f79fa0a4@anl.gov">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><br>
</p>
<div class="moz-cite-prefix">On 11/18/19 4:29 AM, James Henderson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABqSp3mRSiYFUrs-O=XzhQBtY5_3Hs+iB0cwFC7X0h=AzjCKLQ@mail.gmail.com">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Only a single LGTM is required. Reviewers are expected to
only LGTM<br>
patches they're confident in their knowledge of. Reviewers
may review<br>
and provide suggestions, but explicitly defer LGTM to
someone else. <br>
This is encouraged and a good way for new contributors to
learn the code. </blockquote>
<div>Whilst I get what you're trying to say, I'm not
particularly comfortable with this particular suggestion as
it stands: I regularly am one of two or three active
reviewers on something, often spread out over different
timezones, and I might be happy with it, in which case I'd
signal that with an LGTM, but others might not be ready for
it to be committed. Sometimes I'll ask for the author to
wait to commit until one or more of the other reviewers are
happy too, but other times I forget to explicitly say this.
Perhaps a couple of sentences could be added to the end of
this paragraph to capture this approach:<br>
</div>
<div><br>
</div>
<div>"If multiple reviewers have been actively reviewing the
patch, it is generally courteous to allow all of them a
chance to give their LGTM before committing, after one LGTM
has been received. The reviewer who gives the original LGTM
may suggest an appropriate amount of time to wait before
committing in this case."</div>
<div><br>
</div>
<div>What I want to avoid is me (UK timezone) making some
suggestions on a patch proposed by someone e.g. in the US,
then a reviewer from the US getting into an active
discussion, proposing a counter-suggestion, which gets
adopted and LGTMed by that reviewer, resulting in a commit
before I've had a chance to follow up on my comments etc.
Obviously I can make post-commit requests, but sometimes it
feels like the bar for suggestions post-commit is higher,
and therefore my comments might not reach that level etc.</div>
</div>
</blockquote>
<p><br>
</p>
<p>I agree with this. I was planning on proposing wording along
the lines of the following, adding to the original suggestion:</p>
<p>When providing an unqualified LGTM (approval to commit), it is
the responsibility of the reviewer to have reviewed all of the
discussion and feedback from all reviewers ensuring that all
feedback has been addressed and that all other reviewers will
almost surely be satisfied with the patch being approved. If
unsure, the reviewer should provide a qualified approval, (e.g.,
"LGTM, but please wait for @someone, @someone_else"). You may
also do this if you are fairly certain that a particular
community member will wish to review, even if that person hasn't
done so yet (although don't wait for more than one week if that
person has not responded; if you think something is "must see"
by a wider audience, it should have an RFC). If it is likely
that others will want to review a recently-posted patch,
especially if there might be objections, but no one else has
done so yet, it is also polite to provide a qualified approval
(e.g., "LGTM, but please wait for a couple days in case others
wish to review").<br>
</p>
<p>Thoughts?</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CABqSp3mRSiYFUrs-O=XzhQBtY5_3Hs+iB0cwFC7X0h=AzjCKLQ@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>James<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 16 Nov 2019 at
16:37, Philip Reames via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
+ 1 in general, a couple of suggestions<br>
<br>
On 11/14/19 7:46 PM, Finkel, Hal J. via llvm-dev wrote:<br>
> Hi, everyone,<br>
><br>
> I've been fielding an increasing number of questions
about how our <br>
> code-review process in LLVM works from people who are
new to our <br>
> community, and it's been pointed out to me that our
documentation on <br>
> code reviews is both out of date and not as helpful as
it could be to <br>
> new developers.<br>
><br>
> <a
href="http://llvm.org/docs/DeveloperPolicy.html#code-reviews"
rel="noreferrer" target="_blank" moz-do-not-send="true">
http://llvm.org/docs/DeveloperPolicy.html#code-reviews</a><br>
><br>
> I would like to compose a patch to update this, but
before I do that, I <br>
> want to highlight some of my thoughts to get feedback.
My intent is to <br>
> capture our community best practices in writing so that
people new to <br>
> our community understand our processes and
expectations. Here are some <br>
> things that I would like to capture:<br>
><br>
> 1. You do not need to be an expert in some area of
the compiler to <br>
> review patches; it's fine to ask questions about what
some piece of code <br>
> is doing. If it's not clear to you what is going on,
you're unlikely to <br>
> be the only one. Extra comments and/or test cases can
often help (and <br>
> asking for comments in the test cases is fine as well).<br>
Authors are encouraged to interpret questions as reasons to
reexamine<br>
the readability of the code in question. Structural
changes, or further<br>
comments may be appropriate.<br>
><br>
> 2. If you review a patch, but don't intend for the
review process to <br>
> block on your approval, please state that explicitly.
Out of courtesy, <br>
> we generally wait on committing a patch until all
reviewers are <br>
> satisfied, and if you don't intend to look at the patch
again in a <br>
> timely fashion, please communicate that fact in the
review.<br>
><br>
> 3. All comments by reviewers should be addressed by
the patch author. <br>
> It is generally expected that suggested changes will be
incorporated <br>
> into the next revision of the patch unless the author
and/or other <br>
> reviewers can articulate a good reason to do otherwise
(and then the <br>
> reviewers must agree). If you suggest changes in a code
review, but <br>
> don't wish the suggestion to be interpreted this
strongly, please state <br>
> so explicitly.<br>
><br>
> 4. Reviewers may request certain aspects of a patch
to be broken out <br>
> into separate patches for independent review, and also,
reviewers may <br>
> accept a patch conditioned on the author providing a
follow-up patch <br>
> addressing some particular issue or concern (although
no committed patch <br>
> should leave the project in a broken state). Reviewers
can also accept a <br>
> patch conditioned on the author applying some set of
minor updates prior <br>
> to committing, and when applicable, it is polite for
reviewers to do so.<br>
><br>
> 5. Aim to limit the number of iterations in the
review process. For <br>
> example, when suggesting a change, if you want the
author to make a <br>
> similar set of changes at other places in the code,
please explain the <br>
> requested set of changes so that the author can make
all of the changes <br>
> at once. If a patch will require multiple steps prior
to approval (e.g., <br>
> splitting, refactoring, posting data from specific
performance tests), <br>
> please explain as many of these up front as possible.
This allows the <br>
> patch author to make the most-efficient use of his or
her time.<br>
If the path forward is not clear - because the patch is too
large to<br>
meaningful review, or direction needs to be settled - it is
fine to<br>
suggest a clear next step (e.g. landing a refactoring)
followed by a<br>
re-review. Please state explicitly if the path forward is
unclear to<br>
prevent confusions on the part of the author. <br>
><br>
> 6. Some changes are too large for just a code review.
Changes that <br>
> should change the Language Reference (e.g., adding new
<br>
> target-independent intrinsics), adding language
extensions in Clang, and <br>
> so on, require an RFC on *-dev first. For changes that
promise <br>
> significant impact on users and/or downstream code
bases, reviewers can <br>
> request an RFC (Request for Comment) achieving
consensus before <br>
> proceeding with code review. That having been said,
posting initial <br>
> patches can help with discussions on an RFC.<br>
><br>
> Lastly, the current text reads, "Code reviews are
conducted by email on <br>
> the relevant project’s commit mailing list, or
alternatively on the <br>
> project’s development list or bug tracker.", and then
only later <br>
> mentions Phabricator. I'd like to move Phabricator to
be mentioned on <br>
> this line before the other methods.<br>
><br>
> Please let me know what you think.<br>
><br>
> Thanks again,<br>
><br>
> Hal<br>
<br>
A couple of additional things:<br>
<br>
Only a single LGTM is required. Reviewers are expected to
only LGTM<br>
patches they're confident in their knowledge of. Reviewers
may review<br>
and provide suggestions, but explicitly defer LGTM to
someone else. <br>
This is encouraged and a good way for new contributors to
learn the code. <br>
<br>
There is a cultural expectation that at least one reviewer
is from a<br>
different organization than the author of the patch. If
that's not<br>
possible, care should be taken to ensure overall direction
has been<br>
widely accepted. <br>
<br>
Post commit review is encouraged via either phabricator or
email. There<br>
is a strong expectation that authors respond promptly to
post commit<br>
feedback and address it. Failure to do so is cause for the
patch to be<br>
reverted. If substantial problems are identified, it is
expected that<br>
the patch is reverted, fixed offline, and then recommitted
(possibly<br>
after further review.)<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</blockquote>
</body>
</html>