hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From w...@apache.org
Subject svn commit: r1755013 - in /hadoop/common/site/main/author/src/documentation/content/xdocs: committer_criteria.html site.xml versioning.html
Date Wed, 03 Aug 2016 00:29:07 GMT
Author: wang
Date: Wed Aug  3 00:29:07 2016
New Revision: 1755013

URL: http://svn.apache.org/viewvc?rev=1755013&view=rev
Add committer criteria and versioning pages to site.


Added: hadoop/common/site/main/author/src/documentation/content/xdocs/committer_criteria.html
URL: http://svn.apache.org/viewvc/hadoop/common/site/main/author/src/documentation/content/xdocs/committer_criteria.html?rev=1755013&view=auto
--- hadoop/common/site/main/author/src/documentation/content/xdocs/committer_criteria.html
+++ hadoop/common/site/main/author/src/documentation/content/xdocs/committer_criteria.html
Wed Aug  3 00:29:07 2016
@@ -0,0 +1,37 @@
+<?xml version="1.0"?>
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" 
+          "http://forrest.apache.org/dtd/document-v20.dtd">
+  <header> 
+    <title>Apache Hadoop Committer Criteria</title> 
+  </header> 
+  <body> 
+    <section><title>Criteria for Committership</title>
+        <p>Committers are responsible for reviewing and integrating code changes. The
PMC votes to make a contributor a committer based on an assessment of their contributions
to the project. Contributions can be made in many ways, and there is no one route to committership.
That said, here are the general criteria that the PMC looks for from all potential committers:</p>
+        <ul>
+            <li>A history of sustained contribution to the project. This is a way for
a contributor to demonstrate their expertise in an area, and thus their ability to help review
and commit contributions by others in that same area. Sustained contribution is also a way
of demonstrating commitment to the project, essentially that someone will continue contributing
even after they become a committer.</li>
+            <li>High-quality contributions. As experienced contributors, committers
set an example for others in the project, and help inculcate a culture of high-quality contributions.
For code contributions, this means clean, documented code which includes unit tests if appropriate
and passes precommit checks. For reviews, this means thorough, actionable feedback, and a
+1 vote (even non-binding) only when there is a high degree of confidence in the change.</li>
+            <li>Community involvement. Contributors are always expected to be polite,
constructive, and respectful of others during community interactions. Disagreement can (and
will) happen over technical issues, but the discussion should remain friendly and focused
on technical merits. Committers also have the additional responsibility of mentoring newer
contributors, as well as helping to grow the community through actions like responding to
emails on the user and dev list.</li>
+        </ul>
+    </section>
+    <section><title>Example Paths to Committership</title>
+        <p>Here are a few hypothetical example paths to a commit bit:</p>
+        <p>Han Meimei works at a big company operating a large Apache Hadoop cluster.
While deploying the newest version of Hadoop to her staging cluster, she discovers a number
of bugs and performance regressions. She files JIRAs for these issues, and is able to post
patches for some of them. On the remaining JIRAs, she works with other community members by
doing additional debugging on her cluster and testing and reviewing intermediate patches.
Additionally, Han Meimei works with the release manager of the release line, Lei Li, to make
sure critical issues are backported to the next maintenance release. Han Meimei also makes
an effort to help fix and review other critical issues targeted at the next maintenance release,
even though her cluster is not currently affected. She continues doing similar stabilization
work for subsequent maintenance releases in this release line, demonstrating her commitment
to shipping high-quality upstream releases.</p>
+        <p>Elise works at a commercial big data vendor as a developer. Elise ramps
up by doing some newbie JIRAs, but then gets involved with a large cross-company development
effort happening on a feature branch. Elise helps to review the design of the feature, providing
constructive feedback, and works with other community members to divide the work into subtasks.
At this point, the PMC grants Elise branch committership to accelerate development. Elise
submits good patches for a number of subtasks, and shows care and thoroughness when reviewing
and committing code of others. After the feature branch is later merged to trunk, Elise continues
to find and fix bugs related to the feature, as well as reviewing code contributions from
+        <p>Raj works as a test engineer at a commercial big data vendor. Raj notices
the lack of integration testing upstream, and contributes a test harness for fault-injection
testing which is committed to the project. Raj coordinates with the PMC to get the test harness
running on Apache infrastructure, and starts triaging the output and filing JIRAs for relevant
bugs with reproductions. Raj helps with gathering logs and reproducing issues, and continues
making improvements to the test harness.</p>
+        <p>Peter is a technical writer interested in improving Hadoop's documentation.
He starts by fixing outdated information and incorrect examples, reaching out to subject matter
experts and exploring the codebase to clarify technical details. As Peter becomes more familiar
with the set of documentation, he realizes that a newly contributed feature didn't include
sufficient documentation, and contributes a guide on how to setup and use the feature that
also explains some of the design decisions that influenced API design. Peter continues to
broaden his doc contributions to more and more areas, and also is active answering user questions
on the mailing list. This demonstrates his knowledge of the project, attention to detail,
and also his user-focus.</p>
+   </section>

Modified: hadoop/common/site/main/author/src/documentation/content/xdocs/site.xml
URL: http://svn.apache.org/viewvc/hadoop/common/site/main/author/src/documentation/content/xdocs/site.xml?rev=1755013&r1=1755012&r2=1755013&view=diff
--- hadoop/common/site/main/author/src/documentation/content/xdocs/site.xml (original)
+++ hadoop/common/site/main/author/src/documentation/content/xdocs/site.xml Wed Aug  3 00:29:07
@@ -29,6 +29,8 @@
     <thanks      label="Thanks" href="ext:thanks" />
     <privacy      label="Privacy Policy" href="privacy_policy.html" />    
     <bylaws       label="Bylaws" href="bylaws.html"/>
+    <committer       label="Committer criteria" href="committer_criteria.html"/>
+    <versioning       label="Release Versioning" href="versioning.html"/>
     <license label="License" href="ext:license" />

Added: hadoop/common/site/main/author/src/documentation/content/xdocs/versioning.html
URL: http://svn.apache.org/viewvc/hadoop/common/site/main/author/src/documentation/content/xdocs/versioning.html?rev=1755013&view=auto
--- hadoop/common/site/main/author/src/documentation/content/xdocs/versioning.html (added)
+++ hadoop/common/site/main/author/src/documentation/content/xdocs/versioning.html Wed Aug
 3 00:29:07 2016
@@ -0,0 +1,70 @@
+<?xml version="1.0"?>
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" 
+          "http://forrest.apache.org/dtd/document-v20.dtd">
+  <header> 
+    <title>Apache Hadoop Release Versioning</title> 
+  </header> 
+  <body> 
+      <section><title>Background</title>
+          <p>Apache Hadoop uses a version format of <major>.<minor>.<maintenance>,
where each version component is a numeric value. Versions can also have additional suffixes
like "-alpha2" or "-beta1", which denote the API compatibility guarantees and quality of the
release. We use “a.b.c” and “x.y.z” to denote  a dotted version triplet.</p>
+          <p>Major versions are used to introduce substantial, potentially incompatible,
changes. Examples of this include the replacement of MapReduce 1 with YARN and MapReduce 2
in Hadoop 2, and the required Java runtime version from JDK7 to JDK8 in Hadoop 3.</p>
+          <p>Minor versions are used to introduce new compatible features within a
major release line.</p>
+          <p>Maintenance releases include bug fixes or low-risk supportability changes.</p>
+          <p>Hadoop's versioning scheme has evolved over the years. The early days
of 0.20.2 leading up to the 1.y releases saw a plethora of parallel branches with different
featuresets. Release activities coalesced in the early 2.y release era, with a mostly linear
progression of releases from 2.0.0 through 2.7.0.</p>
+          <p>However, the ongoing maintenance of the 2.6.z and 2.7.z re-introduced
parallel active release lines to Hadoop. Additional plans for 2.8.z and 3.0.z releases mean
potentially four active release lines, necessitating clarification on Hadoop versioning and
how it affects these parallel release branches.</p>
+      </section>
+      <section><title>Versioning rules</title>
+          <p>To establish a common foundation of knowledge, we require the following
in terms of release versions.</p>
+          <ul>
+              <li>For a.b.c (maintenance) releases, the "c"s need to be released in
+              <li>For a.b.0 (minor) releases, the "b"s need to be released in order.</li>
+              <li>For a.0.0 (major) releases, it comes after a specific x.y.0 minor
+          </ul>
+          <p>This means that new major releases need to be coordinated with the previous
minor release. New minor and maintenance releases only require coordination within their release
+          <p>"-alphaX" and "-betaX" suffixed version can be treated as a.b.c versions,
with the first (e.g. "-alpha1") being the a.b.0 release.</p>
+          <p>When it comes to setting fix versions, this policy is encoded by the following
set of rules:</p>
+          <ol>
+              <li>For each minor release line, set the lowest unreleased a.b.c version,
where c &ge; 0.</li>
+              <li>For each major release line, set the lowest unreleased a.b.0 version.</li>
+          </ol>
+      </section>
+      <section<title>Example</title>
+          <p>As an example, currently the latest releases in the 2.6.x and 2.7.x lines
are 2.6.4 and 2.7.2. We have also cut the following branches for planned future releases:
branch-2.7.3, branch-2.8, and branch-3.0.0-alpha1.</p>
+          <p>If we are committing a bugfix that is intended for the 2.6.5 release,
we would commit to:</p>
+          <ol>
+              <li>trunk (3.0.0-alpha2)</li>
+              <li>branch-3.0.0-alpha1 (3.0.0-alpha1)</li>
+              <li>branch-2 (2.9.0)</li>
+              <li>branch-2.8 (2.8.0)</li>
+              <li>branch-2.7 (2.7.4)</li>
+              <li>branch-2.7.3 (2.7.3)</li>
+              <li>branch-2.6 (2.6.5)</li>
+          </ol>
+          <p>Applying the above rules for setting fix versions:</p>
+          <ol>
+              <li>Rule 1: 2.6.z and 2.7.z are both minor release lines, so set 2.6.5
and 2.7.3</li>
+              <li>Rule 2: 2.y.z and 3.y.z the major release lines, so set 2.8.0 and
+          </ol>
+          <p>Note that when backporting changes, we always make sure to backport to
the next higher release in a release line. For instance, we make sure to backport to branch-2.7
(2.7.4) when backporting to branch-2.7.3 (2.7.3), and to branch-2 (2.9.0) when backporting
to branch-2.8 (2.8.0). This preserves the monotonicity of releases.</p>
+      </section>
+  </body>

To unsubscribe, e-mail: common-commits-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-commits-help@hadoop.apache.org

View raw message