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 <hka...@apple.com> 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 <hka...@apple.com> 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">d...@spark.apache.org</code> if you have trouble with these steps, or want help doing your first merge.</p> +<p>Ask <code class="language-plaintext highlighter-rouge">d...@spark.apache.org</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/dev@spark.apache.org/msg10284.html"><code class="highlighter-rouge">pwendell</code></a>:</p> +<p>From <a href="https://www.mail-archive.com/dev@spark.apache.org/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: commits-unsubscr...@spark.apache.org For additional commands, e-mail: commits-h...@spark.apache.org