You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by me...@apache.org on 2017/07/12 20:02:55 UTC
[beam-site] branch asf-site updated (7ca1256 -> f88e604)
This is an automated email from the ASF dual-hosted git repository.
mergebot-role pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/beam-site.git.
from 7ca1256 Prepare repository for deployment.
add 4e9082b Drop the word reviewer from the contribution guide
add 87326e1 This closes #273
new f88e604 Prepare repository for deployment.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
content/contribute/contribution-guide/index.html | 16 ++++++++--------
src/contribute/contribution-guide.md | 16 ++++++++--------
2 files changed, 16 insertions(+), 16 deletions(-)
--
To stop receiving notification emails like this one, please contact
['"commits@beam.apache.org" <co...@beam.apache.org>'].
[beam-site] 01/01: Prepare repository for deployment.
Posted by me...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
mergebot-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/beam-site.git
commit f88e604afdcfb9d5b96b5435f3f5209cca787f72
Author: Mergebot <me...@apache.org>
AuthorDate: Wed Jul 12 20:02:53 2017 +0000
Prepare repository for deployment.
---
content/contribute/contribution-guide/index.html | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/content/contribute/contribution-guide/index.html b/content/contribute/contribution-guide/index.html
index 18c6257..d7e89d2 100644
--- a/content/contribute/contribution-guide/index.html
+++ b/content/contribute/contribution-guide/index.html
@@ -522,7 +522,7 @@ $ tox -e lint
<p>Once the initial code is complete and the tests pass, it’s time to start the code review process. We review and discuss all code, no matter who authors it. It’s a great way to build community, since you can learn from other developers, and they become familiar with your contribution. It also builds a strong project by encouraging a high quality bar and keeping code consistent throughout the project.</p>
<h3 id="create-a-pull-request">Create a pull request</h3>
-<p>Organize your commits to make your reviewer’s job easier. Reviewers normally prefer multiple small pull requests, instead of a single large pull request. Within a pull request, a relatively small number of commits that break the problem into logical steps is preferred. For most pull requests, you’ll squash your changes down to 1 commit. You can use the following command to re-order, squash, edit, or change description of individual commits.</p>
+<p>Organize your commits to make a committer’s job easier when reviewing. Committers normally prefer multiple small pull requests, instead of a single large pull request. Within a pull request, a relatively small number of commits that break the problem into logical steps is preferred. For most pull requests, you’ll squash your changes down to 1 commit. You can use the following command to re-order, squash, edit, or change description of individual commits.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>$ git rebase -i origin/master
</code></pre>
@@ -536,25 +536,25 @@ $ tox -e lint
</code></pre>
</div>
-<p>Please include a descriptive pull request message to help make the reviewer’s job easier. It’s fine to refer to existing design docs or the contents of the associated JIRA as appropriate.</p>
+<p>Please include a descriptive pull request message to help make the comitter’s job easier when reviewing. It’s fine to refer to existing design docs or the contents of the associated JIRA as appropriate.</p>
<p>If you know a good committer to review your pull request, please make a comment like the following. If not, don’t worry – a committer will pick it up.</p>
-<div class="highlighter-rouge"><pre class="highlight"><code>Hi @<GitHub-reviewer-username>, can you please take a look?
+<div class="highlighter-rouge"><pre class="highlight"><code>Hi @<GitHub-committer-username>, can you please take a look?
</code></pre>
</div>
-<p>When choosing a reviewer, think about who is the expert on the relevant code, who the stakeholders are for this change, and who else would benefit from becoming familiar with the code. If you’d appreciate comments from additional folks but already have a main reviewer, you can explicitly cc them using <code class="highlighter-rouge">@<GitHub-reviewer-username></code>.</p>
+<p>When choosing a committer to review, think about who is the expert on the relevant code, who the stakeholders are for this change, and who else would benefit from becoming familiar with the code. If you’d appreciate comments from additional folks but already have a main committer, you can explicitly cc them using <code class="highlighter-rouge">@<GitHub-committer-username></code>.</p>
<h3 id="code-review-and-revision">Code Review and Revision</h3>
-<p>During the code review process, don’t rebase your branch or otherwise modify published commits, since this can remove existing comment history and be confusing to the reviewer. When you make a revision, always push it in a new commit.</p>
+<p>During the code review process, don’t rebase your branch or otherwise modify published commits, since this can remove existing comment history and be confusing to the committer when reviewing. When you make a revision, always push it in a new commit.</p>
<p>Our GitHub mirror automatically provides pre-commit testing coverage using Jenkins. Please make sure those tests pass; the contribution cannot be merged otherwise.</p>
<h3 id="lgtm">LGTM</h3>
-<p>Once the reviewer is happy with the change, they’ll respond with an LGTM (“<em>looks good to me!</em>”). At this point, the committer will take over, possibly make some additional touch ups, and merge your changes into the codebase.</p>
+<p>Once the committer is happy with the change, they’ll respond with an LGTM (“<em>looks good to me!</em>”). At this point, the committer will take over, possibly make some additional touch ups, and merge your changes into the codebase.</p>
-<p>In the case both the author and the reviewer are committers, either can merge the pull request. Just be sure to communicate clearly whose responsibility it is in this particular case.</p>
+<p>In the case the author is also a committer, either can merge the pull request. Just be sure to communicate clearly whose responsibility it is in this particular case.</p>
<p>Thank you for your contribution to Beam!</p>
@@ -570,7 +570,7 @@ $ git push <GitHub_user> --delete <my-branch>
</div>
<h2 id="commit-committers-only">Commit (committers only)</h2>
-<p>Once the code has been peer reviewed by a committer, the next step is for the committer to merge it into the <a href="https://git-wip-us.apache.org/repos/asf/beam.git">authoritative Apache repository</a>, not the read-only GitHub mirror. (In the case that the author is also a committer, it is acceptable for either the author or reviewer to do the merge. Just be explicit about whose job it is!)</p>
+<p>Once the code has been peer reviewed by a committer, the next step is for the committer to merge it into the <a href="https://git-wip-us.apache.org/repos/asf/beam.git">authoritative Apache repository</a>, not the read-only GitHub mirror. (In the case that the author is also a committer, it is acceptable for either the author of the change or committer who reviewed the change to do the merge. Just be explicit about whose job it is!)</p>
<p>Pull requests should not be merged before the review has received an explicit LGTM from another committer. Exceptions to this rule may be made rarely, on a case-by-case basis only, in the committer’s discretion for situations such as build breakages.</p>
--
To stop receiving notification emails like this one, please contact
"commits@beam.apache.org" <co...@beam.apache.org>.