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 <bui...@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>