beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From git-site-r...@apache.org
Subject [beam] branch asf-site updated: Publishing website 2019/03/12 18:57:42 at commit 04392f3
Date Tue, 12 Mar 2019 18:57:51 GMT
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 136f2ef  Publishing website 2019/03/12 18:57:42 at commit 04392f3
136f2ef is described below

commit 136f2efbdbb3da38ee2fee407c6d442564d3c82d
Author: jenkins <builds@apache.org>
AuthorDate: Tue Mar 12 18:57:42 2019 +0000

    Publishing website 2019/03/12 18:57:42 at commit 04392f3
---
 .../contribute/committer-guide/index.html          | 44 ++++++++++++----------
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/website/generated-content/contribute/committer-guide/index.html b/website/generated-content/contribute/committer-guide/index.html
index b8b889f..cd5ba82 100644
--- a/website/generated-content/contribute/committer-guide/index.html
+++ b/website/generated-content/contribute/committer-guide/index.html
@@ -260,25 +260,31 @@ but committer may absorb some extra effort for new contributors)</li>
 <h2 id="always-get-to-lgtm-looks-good-to-me">Always get to LGTM (“Looks good to me!”)</h2>
 
 <p>After a pull request goes through rounds of reviews and revisions, it will
-become ready for merge. A committer (who is <em>not</em> the author of the code)
-should signal this either by GitHub “approval” or by a comment such as “Looks
-good to me!” (LGTM). Any committer can then merge the pull request. It is fine
-for a committer to self-merge if another committer has reviewed the code and
-approved it, just be sure to 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 are rare and made on a
-case-by-case basis. A committer may use their discretion for situations such as
-build breaks. In this case, you should still seek a review on the pull request!
-A common acronym you may see is “TBR” – “to be reviewed”.</p>
-
-<p>Committers should never commit anything without going through a pull request,
-because that bypasses test coverage and could potentially cause the build to
-fail. In addition, pull requests ensure that changes are communicated properly
-and potential flaws or improvements can be spotted.  <strong>Always go through a pull
-request, even if you won’t wait for the code review.</strong> Even then, reviewers
-can provide comments in the pull request after the merge happens, for use
-in follow-up pull requests.</p>
+become ready for merge. A reviewer signals their approval either
+by GitHub “approval” or by a comment such as “Looks good to me!” (LGTM).</p>
+
+<ul>
+  <li>If the author of the pull request is not a committer, a committer must be
+the one to approve the change.</li>
+  <li>If the author of the pull request is a committer, approval from their chosen
+reviewer is enough. A committer is trusted to choose an appropriate
+reviewer, even if the reviewer is not a committer.</li>
+</ul>
+
+<p>Once a pull request is approved, any committer can merge it.</p>
+
+<p>Exceptions to this rule are rare and made on a case-by-case basis. A committer
+may use their discretion for situations such as build breaks. In this case, you
+should still seek a review on the pull request!  A common acronym you may see
+is “TBR” – “to be reviewed”.</p>
+
+<p><strong>Always go through a pull request, even if you won’t wait for the
code
+review.</strong> Committers should never commit anything without going through a pull
+request, even when it is an urgent fix or rollback due to build breakage.
+Skipping pull request bypasses test coverage and could potentially cause the
+build to fail, or fail to fix breakage.  In addition, pull requests ensure that
+changes are communicated properly and potential flaws or improvements can be
+spotted, even after the merge happens.</p>
 
 <h2 id="contributor-license-agreement">Contributor License Agreement</h2>
 


Mime
View raw message