You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@drill.apache.org by br...@apache.org on 2016/05/26 18:41:10 UTC
drill-site git commit: update code contribution process
Repository: drill-site
Updated Branches:
refs/heads/asf-site d3a1b3eb2 -> 6b6e4c87d
update code contribution process
Project: http://git-wip-us.apache.org/repos/asf/drill-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/drill-site/commit/6b6e4c87
Tree: http://git-wip-us.apache.org/repos/asf/drill-site/tree/6b6e4c87
Diff: http://git-wip-us.apache.org/repos/asf/drill-site/diff/6b6e4c87
Branch: refs/heads/asf-site
Commit: 6b6e4c87d283c2f8435693d4e26983bd37d8bd46
Parents: d3a1b3e
Author: Bridget Bevens <bb...@maprtech.com>
Authored: Thu May 26 11:40:58 2016 -0700
Committer: Bridget Bevens <bb...@maprtech.com>
Committed: Thu May 26 11:40:58 2016 -0700
----------------------------------------------------------------------
.../index.html | 231 +++++++------------
feed.xml | 4 +-
2 files changed, 86 insertions(+), 149 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/drill-site/blob/6b6e4c87/docs/apache-drill-contribution-guidelines/index.html
----------------------------------------------------------------------
diff --git a/docs/apache-drill-contribution-guidelines/index.html b/docs/apache-drill-contribution-guidelines/index.html
index be19fc2..c834bd0 100644
--- a/docs/apache-drill-contribution-guidelines/index.html
+++ b/docs/apache-drill-contribution-guidelines/index.html
@@ -1064,7 +1064,7 @@
</div>
-
+ May 26, 2016
<link href="/css/docpage.css" rel="stylesheet" type="text/css">
@@ -1077,56 +1077,38 @@ contribution guidelines.</p>
Drill. For ideas about <em>what</em> you might contribute, please see open tickets in
<a href="https://issues.apache.org/jira/browse/DRILL">Jira</a>.</p>
-<h2 id="how-to-contribute-to-drill">How to Contribute to Drill</h2>
+<h2 id="code-contribution-steps">Code Contribution Steps</h2>
-<p>These guidelines include the following topics:</p>
+<p>The following steps outline the process for contributing code to the Apache Drill project:</p>
<ul>
-<li>Getting the source code</li>
-<li>Making Changes
-
-<ul>
-<li>Coding Convention</li>
-<li>Formatter configuration</li>
-<li>Understanding Maven</li>
-<li>Creating a patch</li>
-<li>Applying a patch</li>
-</ul></li>
-<li>Where is a good place to start contributing?</li>
-<li>Contributing your work</li>
-<li>JIRA Guidelines</li>
-<li>See Also</li>
+<li>Step 1: Get the source code.</li>
+<li>Step 2: Get approval and modify the source code.</li>
+<li>Step 3: Get your code reviewed and committed to the project.<br></li>
</ul>
-<h2 id="getting-the-source-code">Getting the source code</h2>
+<p>You may also be interested in the <a href="/docs/apache-drill-contribution-guidelines/#additional-information">additional information</a> at the end of this document. </p>
-<p>First, you need the Drill source code.</p>
+<h2 id="step-1:-get-the-source-code.">Step 1: Get the source code.</h2>
-<p>Get the source code on your local drive using Git. Most development is done on
-"master":</p>
+<p>First, you need the Drill source code. You can use Git to put the source code on your local drive. Most development is done on "master."</p>
<div class="highlight"><pre><code class="language-text" data-lang="text">git clone https://git-wip-us.apache.org/repos/asf/drill.git
</code></pre></div>
-<h2 id="making-changes">Making Changes</h2>
+<h2 id="step-2:-get-approval-and-modify-the-source-code.">Step 2: Get approval and modify the source code.</h2>
-<p>Before you start, send a message to the <a href="http://mail-archives.apache.org/mod_mbox/drill-dev/">Drill developer mailing list</a>, or file a bug
-report in <a href="https://issues.apache.org/jira/browse/DRILL">JIRA</a>. Describe your
-proposed changes and check that they fit in with what others are doing and
-have planned for the project. Be patient, it may take folks a while to
-understand your requirements.</p>
+<p>Before you start, send a message to the <a href="http://mail-archives.apache.org/mod_mbox/drill-dev/">Drill developer mailing list</a> or file a bug report in <a href="https://issues.apache.org/jira/browse/DRILL">JIRA</a> describing your proposed changes. Doing this helps to verify that your changes will work with what others are doing and have planned for the project. Be patient, it may take folks a while to understand your requirements.</p>
-<p>Modify the source code and add some features using your favorite IDE.</p>
+<p>Once your suggested changes are approved, you can modify the source code and add some features using your favorite IDE.</p>
+
+<p>The following sections provide tips for working on the project:</p>
<h3 id="coding-convention">Coding Convention</h3>
-<p>Please take care about the following points</p>
+<p>Please adhere to the points outlined below:</p>
<ul>
-<li>All public classes and methods should have informative <a href="http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html">Javadoc comments</a>.
-
-<ul>
-<li>Do not use @author tags.</li>
-</ul></li>
-<li>Code should be formatted according to <a href="http://www.oracle.com/technetwork/java/codeconvtoc-136057.html">Sun's conventions</a>, with one exception:
+<li>All public classes and methods should have informative <a href="http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html">Javadoc comments</a>. Do not use @author tags.</li>
+<li>Code should be formatted according to <a href="http://www.oracle.com/technetwork/java/codeconvtoc-136057.html">Sun's conventions</a>, with the following exceptions:
<ul>
<li>Indent two (2) spaces per level, not four (4).</li>
@@ -1134,153 +1116,107 @@ understand your requirements.</p>
</ul></li>
<li>Contributions should not introduce new Checkstyle violations.</li>
<li>Contributions should pass existing unit tests.</li>
-<li>New unit tests should be provided to demonstrate bugs and fixes. <a href="http://www.junit.org">JUnit</a> 4.1 is our test framework:
+<li>New unit tests should be provided to demonstrate bugs and fixes. <a href="http://www.junit.org">JUnit</a> 4.1 is our test framework which has the following requirements:
<ul>
-<li>You must implement a class that contain test methods annotated with JUnit's 4.x @Test annotation and whose class name ends with <code>Test</code>.</li>
+<li>You must implement a class that contains test methods annotated with JUnit's 4.x @Test annotation and whose class name ends with <code>Test</code>.</li>
<li>Define methods within your class whose names begin with <code>test</code>, and call JUnit's many assert methods to verify conditions; these methods will be executed when you run <code>mvn clean test</code>.</li>
</ul></li>
</ul>
-<h3 id="formatter-configuration">Formatter configuration</h3>
+<h3 id="formatter-configuration">Formatter Configuration</h3>
<p>Setting up IDE formatters is recommended and can be done by importing the
following settings into your browser:</p>
-<p>IntelliJ IDEA formatter: <a href="https://cwiki.apache.org/confluence/download/attachments/29687985/intellij-idea-settings.jar?version=1&modificationDate=1381928827000&api=v2">settings
-jar</a></p>
-
-<p>Eclipse: <a href="https://issues.apache.org/jira/secure/attachment/12474245/eclipse_formatter_apache.xml">formatter xml</a></p>
+<ul>
+<li>IntelliJ IDEA formatter: <a href="https://cwiki.apache.org/confluence/download/attachments/29687985/intellij-idea-settings.jar?version=1&modificationDate=1381928827000&api=v2">settings
+jar</a></li>
+<li>Eclipse: <a href="https://issues.apache.org/jira/secure/attachment/12474245/eclipse_formatter_apache.xml">formatter xml</a></li>
+</ul>
<h3 id="understanding-maven">Understanding Maven</h3>
-<p>Drill is built by Maven, a Java build tool.</p>
+<p>You can use the Maven Java build tool to build Drill. To get started with Maven, see the <a href="http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html">Maven tutorial</a>.</p>
-<ul>
-<li>Good Maven tutorial: <a href="http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html">http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html</a></li>
-</ul>
-
-<p>To build Drill, run</p>
+<p>To build Drill with Maven, run the following command:</p>
<div class="highlight"><pre><code class="language-text" data-lang="text">mvn clean install
</code></pre></div>
-<h3 id="creating-a-patch">Creating a patch</h3>
+<h2 id="step-3:-get-your-code-reviewed-and-committed-to-the-project.">Step 3: Get your code reviewed and committed to the project.</h2>
-<p>Check to see what files you have modified:</p>
-<div class="highlight"><pre><code class="language-text" data-lang="text">git status
-</code></pre></div>
-<p>Add any new files with:</p>
-<div class="highlight"><pre><code class="language-text" data-lang="text">git add .../MyNewClass.java
-git add .../TestMyNewClass.java
-git add .../XXXXXX.q
-git add .../XXXXXX.q.out
-</code></pre></div>
-<p>In order to create a patch, type (from the base directory of drill):</p>
-<div class="highlight"><pre><code class="language-text" data-lang="text">git format-patch origin/master --stdout > DRILL-1234.1.patch.txt
-</code></pre></div>
-<p>This will report all modifications done on Drill sources on your local disk
-and save them into the <em>DRILL-1234.1.patch.txt</em> file. Read the patch file.
-Make sure it includes ONLY the modifications required to fix a single issue.</p>
+<p>This section describes the GitHub pull request-based review process for Apache Drill. </p>
-<p>Please do not:</p>
+<div class="admonition note">
+ <p class="first admonition-title">Note</p>
+ <p class="last">JIRA remains the primary site for discussions on issues. We are not using the GitHub issue tracker. </p>
+</div>
-<ul>
-<li>reformat code unrelated to the bug being fixed: formatting changes should be separate patches/commits.</li>
-<li>comment out code that is now obsolete: just remove it.</li>
-<li>insert comments around each change, marking the change: folks can use subversion to figure out what's changed and by whom.</li>
-<li>make things public which are not required by end users.</li>
-</ul>
+<p>The following steps outline the code review and commit process required to contribute new code to the Apache Drill project: </p>
-<p>Please do:</p>
+<ol>
+<li>The contributor writes the code that addresses a specific JIRA report as a contribution to the Apache Drill project.</li>
+<li> The contributor organizes (squashes) their code into commits that segregate out refactoring/reorg, as necessary, to enable efficient review. The following list identifies how to combine code into commits:<br>
<ul>
-<li>try to adhere to the coding style of files you edit;</li>
-<li>comment code whose function or rationale is not obvious;</li>
-<li>update documentation (e.g., <em>package.html</em> files, this wiki, etc.)</li>
-</ul>
-
-<h3 id="updating-a-patch">Updating a patch</h3>
-
-<p>For patch updates, our convention is to number them like
-DRILL-1856.1.patch.txt, DRILL-1856.2.patch.txt, etc. And then click the
-"Submit Patch" button again when a new one is uploaded; this makes sure it
-gets back into the review queue. Appending '.txt' to the patch file name makes
-it easy to quickly view the contents of the patch in a web browser.</p>
-
-<h3 id="applying-a-patch">Applying a patch</h3>
+<li>Combine WIP and other small commits together.</li>
+<li>Address multiple JIRAs, for smaller bug fixes or enhancements, with a single commit.</li>
+<li>Use separate commits to allow efficient review, separating out formatting changes or simple refactoring from core changes or additions.</li>
+<li>Rebase this chain of commits on top of the current master.<br>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">The discussion that is automatically copied over from GitHub adds the review process into the Apache infrastructure. The final commit ends up in the Apache Git repo, which is the critical part. As such, there is no requirement to have your intermediate work placed anywhere outside of the GitHub pull request. </p>
+</div><br></li>
+</ul></li>
+<li><p>The contributor opens a pull request against the GitHub mirror, based on the branch that contains their work, which has been squashed together as described in step 2.</p>
-<p>To apply a patch either you generated or found from JIRA, you can issue</p>
-<div class="highlight"><pre><code class="language-text" data-lang="text">git am < cool_patch.patch
-</code></pre></div>
-<p>if you just want to check whether the patch applies you can run patch with
---dry-run option.</p>
+<ul>
+<li>Open the pull request against this repo: <a href="https://github.com/apache/drill/">https://github.com/apache/drill/</a></li>
+<li>Mention the JIRA number in the heading of the pull request, like \u201cDRILL-3000\u201d to automatically link to JIRA.</li>
+<li>For more information about pull requests, see <a href="https://help.github.com/articles/using-pull-requests/">Using Pull Requests</a>.</li>
+</ul></li>
+<li><p>The contributor asks a committer who has experience with the affected component for review.
+This information can be found in the <a href="https://issues.apache.org/jira/browse/DRILL/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel">component owners</a> section of JIRA, or by running <code>git blame</code> on the primary files changed in the pull request. For pull requests that affect multiple areas, send a message to the dev list to find a reviewer.</p></li>
+<li><p>The contributor assigns the JIRA to the reviewer and marks the status as REVIEWABLE.</p></li>
+<li><p>The reviewer reviews the pull request in GitHub and adds comments or a +1 to the general discussion if the pull request is ready to commit. </p>
-<h3 id="review-process">Review Process</h3>
+<ul>
+<li>If there are issues to address, the reviewer changes the JIRA status to "In Progress" and assigns the JIRA back to the contributing author.</li>
+<li>If the reviewer gives a +1, the contributor should continue to step 9 in this process.</li>
+</ul></li>
+<li><p>The contributor addresses review comments. This can be done with new commits on the branch or with work made on the branch locally, squashed into the commit(s) posted in the original pull request and force pushed to the branch the pull request is based on.</p></li>
+<li><p>Return to step 5.</p></li>
+<li><p>A Drill committer completes the following steps to commit the patch:</p>
<ul>
-<li>Use Hadoop's <a href="http://wiki.apache.org/hadoop/CodeReviewChecklist">code review checklist</a> as a rough guide when doing reviews.</li>
-<li>In JIRA, use attach file to notify that you've submitted a patch for that issue.</li>
-<li>Create a Review Request in <a href="https://reviews.apache.org/r/">Review Board</a>. The review request's name should start with the JIRA issue number (e.g. DRILL-XX) and should be assigned to the "drill-git" group.</li>
-<li>If a committer requests changes, set the issue status to 'Resume Progress', then once you're ready, submit an updated patch with necessary fixes and then request another round of review with 'Submit Patch' again.</li>
-<li>Once your patch is accepted, be sure to upload a final version which grants rights to the ASF.</li>
-</ul>
+<li>If the master branch has moved forward since the review, rebase the branch from the pull request on the latest master and re-run tests. </li>
+<li><p>If all tests pass, the committer amends the last commit message in the series to include "this closes #1234", where 1234 is the pull request number, not the JIRA number. This can be done with interactive rebase. When on the branch issue: </p>
+<div class="highlight"><pre><code class="language-text" data-lang="text"> git rebase -i HEAD^
+</code></pre></div></li>
+<li><p>Change where it says \u201cpick\u201d on the line with the last commit, replacing it with \u201cr\u201d or \u201creword\u201d. It replays the commit giving you the opportunity the change the commit message. </p></li>
+<li><p>The committer pushes the commit(s) to the Apache repo (the GitHub repo is just a read-only mirror). </p></li>
+<li><p>The committer resolves the JIRA with a message like <code>"Fixed in <Git commit SHA>"</code>.</p></li>
+</ul></li>
+</ol>
+
+<h2 id="additional-information">Additional Information</h2>
-<h2 id="where-is-a-good-place-to-start-contributing?">Where is a good place to start contributing?</h2>
+<h3 id="where-is-a-good-place-to-start-contributing?">Where is a good place to start contributing?</h3>
<p>After getting the source code, building and running a few simple queries, one
-of the simplest places to start is to implement a DrillFunc.<br>
-DrillFuncs is way that Drill express all scalar functions (UDF or system).<br>
-First you can put together a JIRA for one of the DrillFunc's we don't yet have
-but should (referencing the capabilities of something like Postgres<br>
+of the simplest places to start is to implement a DrillFunc. DrillFuncs are the way that Drill expresses all scalar functions (UDF or system). </p>
+
+<p>First you can put together a JIRA for one of the DrillFuncs that we don't yet have, but should (referencing the capabilities of something like Postgres<br>
or SQL Server). Then try to implement one.</p>
-<p>One example DrillFunc:</p>
+<p>See this example DrillFunc:</p>
<p><a href="https://github.com/apache/drill/blob/3f93454f014196a4da198ce012b605b70081fde0/exec/java-exec/src/main/codegen/templates/ComparisonFunctions.java">ComparisonFunctions.java</a></p>
-<p>Also one can visit the JIRA issues and implement one of those too. </p>
+<p>Also, you can visit the JIRA issues and implement one of those too. </p>
<p>More contribution ideas are located on the <a href="/docs/apache-drill-contribution-ideas">Contribution Ideas</a> page.</p>
-<h3 id="contributing-your-work">Contributing your work</h3>
-
-<p>Finally, patches should be <em>attached</em> to an issue report in
-<a href="http://issues.apache.org/jira/browse/DRILL">JIRA</a> via the <strong>Attach File</strong>
-link on the issue's JIRA. Please add a comment that asks for a code review.
-Please note that the attachment should be granted license to ASF for inclusion
-in ASF works (as per the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache
-License</a>.</p>
-
-<p>Folks should run <code>mvn clean install</code> before submitting a patch. Tests should
-all pass. If your patch involves performance optimizations, they should be
-validated by benchmarks that demonstrate an improvement.</p>
-
-<p>If your patch creates an incompatibility with the latest major release, then
-you must set the <strong>Incompatible change</strong> flag on the issue's JIRA 'and' fill
-in the <strong>Release Note</strong> field with an explanation of the impact of the
-incompatibility and the necessary steps users must take.</p>
-
-<p>If your patch implements a major feature or improvement, then you must fill in
-the <strong>Release Note</strong> field on the issue's JIRA with an explanation of the
-feature that will be comprehensible by the end user.</p>
-
-<p>A committer should evaluate the patch within a few days and either: commit it;
-or reject it with an explanation.</p>
-
-<p>Please be patient. Committers are busy people too. If no one responds to your
-patch after a few days, please make friendly reminders. Please incorporate
-other's suggestions into your patch if you think they're reasonable. Finally,
-remember that even a patch that is not committed is useful to the community.</p>
-
-<p>Should your patch receive a "-1" select the <strong>Resume Progress</strong> on the issue's
-JIRA, upload a new patch with necessary fixes, and then select the <strong>Submit
-Patch</strong> link again.</p>
-
-<p>Committers: for non-trivial changes, it is best to get another committer to
-review your patches before commit. Use <strong>Submit Patch</strong> link like other
-contributors, and then wait for a "+1" from another committer before
-committing. Please also try to frequently review things in the patch queue.</p>
-
-<h2 id="jira-guidelines">JIRA Guidelines</h2>
+<h3 id="what-are-the-jira-guidelines?">What are the JIRA guidelines?</h3>
<p>Please comment on issues in JIRA, making their concerns known. Please also
vote for issues that are a high priority for you.</p>
@@ -1294,10 +1230,11 @@ JIRA's automatically sent messages. If you change your mind, note this in a
new comment, rather than editing an older comment. The issue should preserve
this history of the discussion.</p>
-<h2 id="see-also">See Also</h2>
+<h3 id="see-also">See Also</h3>
<ul>
-<li><a href="http://www.apache.org/dev/contributors.html">Apache contributor documentation</a></li>
+<li>[Apache contributor documentation](<a href="http://www.apache.org/">http://www.apache.org/</a></li>
+<li>dev/contributors.html)</li>
<li><a href="http://www.apache.org/foundation/voting.html">Apache voting documentation</a></li>
</ul>
http://git-wip-us.apache.org/repos/asf/drill-site/blob/6b6e4c87/feed.xml
----------------------------------------------------------------------
diff --git a/feed.xml b/feed.xml
index b27fcbd..07a228e 100644
--- a/feed.xml
+++ b/feed.xml
@@ -6,8 +6,8 @@
</description>
<link>/</link>
<atom:link href="/feed.xml" rel="self" type="application/rss+xml"/>
- <pubDate>Fri, 20 May 2016 10:54:25 -0700</pubDate>
- <lastBuildDate>Fri, 20 May 2016 10:54:25 -0700</lastBuildDate>
+ <pubDate>Thu, 26 May 2016 11:38:31 -0700</pubDate>
+ <lastBuildDate>Thu, 26 May 2016 11:38:31 -0700</lastBuildDate>
<generator>Jekyll v2.5.2</generator>
<item>