This is an automated email from the ASF dual-hosted git repository.
holden pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/spark-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new a3f618b Update committer guide
a3f618b is described below
commit a3f618bec99e5b4132c6586f12c1313b34cf5b13
Author: Holden Karau <[email protected]>
AuthorDate: Mon Aug 24 10:59:16 2020 -0700
Update committer guide
Update the committer guide with the new policy we voted on for when to
commit.
Author: Holden Karau <[email protected]>
Closes #284 from holdenk/update-committer-guide.
---
committers.md | 21 +++++++++++++++++++++
site/committers.html | 42 +++++++++++++++++++++++++++++-------------
2 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/committers.md b/committers.md
index 2665e0a..fc6958c 100644
--- a/committers.md
+++ b/committers.md
@@ -132,6 +132,27 @@ In particular, if you are working on an area of the
codebase you are unfamiliar
Git history for that code to see who reviewed patches before. You can do this
using
`git log --format=full <filename>`, by examining the "Commit" field to see who
committed each patch.
+<h3>When to commit/merge a pull request</h3>
+
+PRs shall not be merged during active, on-topic discussion unless they address
issues such as critical security fixes of a public vulnerability. Under
extenuating circumstances, PRs may be merged during active, off-topic
discussion and the discussion directed to a more appropriate venue. Time should
be given prior to merging for those involved with the conversation to explain
if they believe they are on-topic.
+
+Lazy consensus requires giving time for discussion to settle while
understanding that people may not be working on Spark as their full-time job
and may take holidays. It is believed that by doing this, we can limit how
often people feel the need to exercise their veto.
+
+
+All -1s with justification merit discussion. A -1 from a non-committer can be
overridden only with input from multiple committers, and suitable time must be
offered for any committer to raise concerns. A -1 from a committer who cannot
be reached requires a consensus vote of the PMC under ASF voting rules to
determine the next steps within the [ASF guidelines for code
vetoes](https://www.apache.org/foundation/voting.html).
+
+
+These policies serve to reiterate the core principle that code must not be
merged with a pending veto or before a consensus has been reached (lazy or
otherwise).
+
+
+It is the PMC’s hope that vetoes continue to be infrequent, and when they
occur, that all parties will take the time to build consensus prior to
additional feature work.
+
+
+Being a committer means exercising your judgement while working in a community
of people with diverse views. There is nothing wrong in getting a second (or
third or fourth) opinion when you are uncertain. Thank you for your dedication
to the Spark project; it is appreciated by the developers and users of Spark.
+
+
+It is hoped that these guidelines do not slow down development; rather, by
removing some of the uncertainty, the goal is to make it easier for us to reach
consensus. If you have ideas on how to improve these guidelines or other Spark
project operating procedures, you should reach out on the dev@ list to start
the discussion.
+
<h3>How to Merge a Pull Request</h3>
Changes pushed to the master branch on Apache cannot be removed; that is, we
can't force-push to
diff --git a/site/committers.html b/site/committers.html
index 91bc57b..ff09913 100644
--- a/site/committers.html
+++ b/site/committers.html
@@ -565,7 +565,23 @@ who have shown they understand and can help with these
activities.</p>
<a href="/contributing.html">Contributing to Spark</a>.
In particular, if you are working on an area of the codebase you are
unfamiliar with, look at the
Git history for that code to see who reviewed patches before. You can do this
using
-<code class="highlighter-rouge">git log --format=full <filename></code>,
by examining the “Commit” field to see who committed each patch.</p>
+<code class="language-plaintext highlighter-rouge">git log --format=full
<filename></code>, by examining the “Commit” field to see who
committed each patch.</p>
+
+<h3>When to commit/merge a pull request</h3>
+
+<p>PRs shall not be merged during active, on-topic discussion unless they
address issues such as critical security fixes of a public vulnerability. Under
extenuating circumstances, PRs may be merged during active, off-topic
discussion and the discussion directed to a more appropriate venue. Time should
be given prior to merging for those involved with the conversation to explain
if they believe they are on-topic.</p>
+
+<p>Lazy consensus requires giving time for discussion to settle while
understanding that people may not be working on Spark as their full-time job
and may take holidays. It is believed that by doing this, we can limit how
often people feel the need to exercise their veto.</p>
+
+<p>All -1s with justification merit discussion. A -1 from a non-committer can
be overridden only with input from multiple committers, and suitable time must
be offered for any committer to raise concerns. A -1 from a committer who
cannot be reached requires a consensus vote of the PMC under ASF voting rules
to determine the next steps within the <a
href="https://www.apache.org/foundation/voting.html";>ASF guidelines for code
vetoes</a>.</p>
+
+<p>These policies serve to reiterate the core principle that code must not be
merged with a pending veto or before a consensus has been reached (lazy or
otherwise).</p>
+
+<p>It is the PMC’s hope that vetoes continue to be infrequent, and when they
occur, that all parties will take the time to build consensus prior to
additional feature work.</p>
+
+<p>Being a committer means exercising your judgement while working in a
community of people with diverse views. There is nothing wrong in getting a
second (or third or fourth) opinion when you are uncertain. Thank you for your
dedication to the Spark project; it is appreciated by the developers and users
of Spark.</p>
+
+<p>It is hoped that these guidelines do not slow down development; rather, by
removing some of the uncertainty, the goal is to make it easier for us to reach
consensus. If you have ideas on how to improve these guidelines or other Spark
project operating procedures, you should reach out on the dev@ list to start
the discussion.</p>
<h3>How to Merge a Pull Request</h3>
@@ -574,16 +590,16 @@ it. So please don’t add any test commits or
anything like that, only real
<h4>Setting up Remotes</h4>
-<p>To use the <code class="highlighter-rouge">merge_spark_pr.py</code> script
described below, you
-will need to add a git remote called <code
class="highlighter-rouge">apache</code> at <code
class="highlighter-rouge">https://github.com/apache/spark</code>,
-as well as one called <code class="highlighter-rouge">apache-github</code> at
<code class="highlighter-rouge">git://github.com/apache/spark</code>.</p>
+<p>To use the <code class="language-plaintext
highlighter-rouge">merge_spark_pr.py</code> script described below, you
+will need to add a git remote called <code class="language-plaintext
highlighter-rouge">apache</code> at <code class="language-plaintext
highlighter-rouge">https://github.com/apache/spark</code>,
+as well as one called <code class="language-plaintext
highlighter-rouge">apache-github</code> at <code class="language-plaintext
highlighter-rouge">git://github.com/apache/spark</code>.</p>
-<p>You will likely also have a remote <code
class="highlighter-rouge">origin</code> pointing to your fork of Spark, and
-<code class="highlighter-rouge">upstream</code> pointing to the <code
class="highlighter-rouge">apache/spark</code> GitHub repo.</p>
+<p>You will likely also have a remote <code class="language-plaintext
highlighter-rouge">origin</code> pointing to your fork of Spark, and
+<code class="language-plaintext highlighter-rouge">upstream</code> pointing to
the <code class="language-plaintext highlighter-rouge">apache/spark</code>
GitHub repo.</p>
-<p>If correct, your <code class="highlighter-rouge">git remote -v</code>
should look like:</p>
+<p>If correct, your <code class="language-plaintext highlighter-rouge">git
remote -v</code> should look like:</p>
-<div class="highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>apache https://github.com/apache/spark.git (fetch)
+<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>apache https://github.com/apache/spark.git (fetch)
apache https://github.com/apache/spark.git (push)
apache-github git://github.com/apache/spark (fetch)
apache-github git://github.com/apache/spark (push)
@@ -593,7 +609,7 @@ upstream https://github.com/apache/spark.git (fetch)
upstream https://github.com/apache/spark.git (push)
</code></pre></div></div>
-<p>For the <code class="highlighter-rouge">apache</code> repo, you will need
to set up command-line authentication to GitHub. This may
+<p>For the <code class="language-plaintext highlighter-rouge">apache</code>
repo, you will need to set up command-line authentication to GitHub. This may
include setting up an SSH key and/or personal access token. See:</p>
<ul>
@@ -601,7 +617,7 @@ include setting up an SSH key and/or personal access token.
See:</p>
<li>https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/</li>
</ul>
-<p>Ask <code class="highlighter-rouge">[email protected]</code> if you
have trouble with these steps, or want help doing your first merge.</p>
+<p>Ask <code class="language-plaintext
highlighter-rouge">[email protected]</code> if you have trouble with these
steps, or want help doing your first merge.</p>
<h4>Merge Script</h4>
@@ -613,9 +629,9 @@ which squashes the pull request’s changes into one
commit.</p>
<p>If you want to amend a commit before merging – which should be used for
trivial touch-ups –
then simply let the script wait at the point where it asks you if you want to
push to Apache.
-Then, in a separate window, modify the code and push a commit. Run <code
class="highlighter-rouge">git rebase -i HEAD~2</code> and
+Then, in a separate window, modify the code and push a commit. Run <code
class="language-plaintext highlighter-rouge">git rebase -i HEAD~2</code> and
“squash” your new commit. Edit the commit message just after to
remove your commit message.
-You can verify the result is one change with <code
class="highlighter-rouge">git log</code>. Then resume the script in the other
window.</p>
+You can verify the result is one change with <code class="language-plaintext
highlighter-rouge">git log</code>. Then resume the script in the other
window.</p>
<p>Also, please remember to set Assignee on JIRAs where applicable when they
are resolved. The script
can do this automatically in most cases. However where the contributor is not
yet a part of the
@@ -627,7 +643,7 @@
https://issues.apache.org/jira/plugins/servlet/project-config/SPARK/roles .</p>
<h3>Policy on Backporting Bug Fixes</h3>
-<p>From <a
href="https://www.mail-archive.com/[email protected]/msg10284.html";><code
class="highlighter-rouge">pwendell</code></a>:</p>
+<p>From <a
href="https://www.mail-archive.com/[email protected]/msg10284.html";><code
class="language-plaintext highlighter-rouge">pwendell</code></a>:</p>
<p>The trade off when backporting is you get to deliver the fix to people
running older versions
(great!), but you risk introducing new or even worse bugs in maintenance
releases (bad!).
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
