You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by gi...@apache.org on 2019/10/18 21:47:40 UTC

[beam] branch asf-site updated: Publishing website 2019/10/18 21:47:27 at commit 9231341

This is an automated email from the ASF dual-hosted git repository.

git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/beam.git


The following commit(s) were added to refs/heads/asf-site by this push:
     new 8daf890  Publishing website 2019/10/18 21:47:27 at commit 9231341
8daf890 is described below

commit 8daf89033312dc8a470b4c21b63fdf27eb4be0f1
Author: jenkins <bu...@apache.org>
AuthorDate: Fri Oct 18 21:47:27 2019 +0000

    Publishing website 2019/10/18 21:47:27 at commit 9231341
---
 website/generated-content/contribute/index.html | 59 +++++++++++++++++++------
 1 file changed, 45 insertions(+), 14 deletions(-)

diff --git a/website/generated-content/contribute/index.html b/website/generated-content/contribute/index.html
index 458d89b..a33c827 100644
--- a/website/generated-content/contribute/index.html
+++ b/website/generated-content/contribute/index.html
@@ -225,6 +225,7 @@
       <li><a href="#share-your-intent">Share your intent</a></li>
       <li><a href="#development-setup">Development Setup</a></li>
       <li><a href="#make-your-change">Make your change</a></li>
+      <li><a href="#make-reviewers-job-easier">Make reviewer’s job easier</a></li>
     </ul>
   </li>
   <li><a href="#when-will-my-change-show-up-in-an-apache-beam-release">When will my change show up in an Apache Beam release?</a></li>
@@ -400,15 +401,24 @@ environment. See the Developers’ wiki for tips, guides, and FAQs on:
 <h3 id="make-your-change">Make your change</h3>
 
 <ol>
-  <li>Make your code change. Every source file needs to include the Apache license header. Every new dependency needs to
-have an open source license <a href="https://www.apache.org/legal/resolved.html#criteria">compatible</a> with Apache.</li>
-  <li>Add unit tests for your change</li>
-  <li>When your change is ready to be reviewed and merged, create a pull request.
-Format commit messages and the pull request title like <code class="highlighter-rouge">[BEAM-XXX] Fixes bug in ApproximateQuantiles</code>,
+  <li>
+    <p>Make your code change. Every source file needs to include the Apache license header. Every new dependency needs to
+have an open source license <a href="https://www.apache.org/legal/resolved.html#criteria">compatible</a> with Apache.</p>
+  </li>
+  <li>
+    <p>Add unit tests for your change.</p>
+  </li>
+  <li>
+    <p>Use descriptive commit messages that make it easy to identify changes and provide a clear history.</p>
+  </li>
+  <li>
+    <p>When your change is ready to be reviewed and merged, create a pull request.</p>
+  </li>
+  <li>
+    <p>Format commit messages and the pull request title like <code class="highlighter-rouge">[BEAM-XXX] Fixes bug in ApproximateQuantiles</code>,
 where you replace BEAM-XXX with the appropriate JIRA issue.
-This will automatically link the pull request to the issue.
-Use descriptive commit messages that make it easy to identify changes and provide a clear history.
-To support efficient and quality review, avoid tiny or out-of-context changes and huge mega-changes.</li>
+This will automatically link the pull request to the issue.</p>
+  </li>
   <li>
     <p>The pull request and any changes pushed to it will trigger <a href="https://cwiki.apache.org/confluence/display/BEAM/Contribution+Testing+Guide#ContributionTestingGuide-Pre-commit">pre-commit
 jobs</a>. If a test fails and appears unrelated to your
@@ -419,9 +429,8 @@ PR</p>
 </code></pre>
     </div>
 
-    <p>There are other trigger phrases for post-commit tests found in
-.testinfra/jenkins, but use these sparingly because post-commit
-tests consume shared development resources.</p>
+    <p>Pull request template has a link to a <a href="https://github.com/apache/beam/blob/master/.test-infra/jenkins/README.md">catalog of trigger phrases</a>
+that start various post-commit tests suites. Use these sparingly because post-commit tests consume shared development resources.</p>
   </li>
   <li>Pull requests can only be merged by a
 <a href="/contribute/team/">Beam committer</a>.
@@ -436,9 +445,31 @@ To find a committer for your area, either:
   </li>
   <li>If you don’t get any response in 3 business days, email the <a href="/community/contact-us">dev@ mailing list</a> to ask for someone to look at your pull
 request.</li>
-  <li>Review feedback typically leads to follow-up changes. You can add these changes as additional “fixup” commits to the
-existing PR/branch. This will allow reviewer(s) to track the incremental progress. After review is complete and the
-PR accepted, multiple commits should be squashed (see <a href="https://cwiki.apache.org/confluence/display/BEAM/Git+Tips">Git workflow tips</a>).</li>
+</ol>
+
+<h3 id="make-reviewers-job-easier">Make reviewer’s job easier</h3>
+
+<ol>
+  <li>
+    <p>Provide context for your changes in the associated JIRA issue and/or PR description.</p>
+  </li>
+  <li>
+    <p>Avoid huge mega-changes.</p>
+  </li>
+  <li>
+    <p>Review feedback typically leads to follow-up changes. It is easier to review follow-up changes when they are added as additional “fixup” commits to the
+existing PR/branch. This allows reviewer(s) to track the incremental progress and focus on new changes,
+and keeps comment threads attached to the code.
+Please refrain from squashing new commits into reviewed commits before review is completed.
+Because squashing reviewed and unreviewed commits often makes it harder to
+see the the difference between the review iterations, reviewers may ask you to unsquash new changes.</p>
+  </li>
+  <li>
+    <p>After review is complete and the PR is accepted, fixup commits should be squashed (see <a href="https://cwiki.apache.org/confluence/display/BEAM/Git+Tips">Git workflow tips</a>).
+Beam committers <a href="https://beam.apache.org/contribute/committer-guide/#merging-it">can squash</a>
+all commits in the PR during merge, however if a PR has a mixture of independent changes that should not be squashed, and fixup commits,
+then the PR author should help squashing fixup commits to maintain a clean commmit history.</p>
+  </li>
 </ol>
 
 <h2 id="when-will-my-change-show-up-in-an-apache-beam-release">When will my change show up in an Apache Beam release?</h2>