src/main/docbkx/community.xml - hbase - Git at Google

 <?xml version="1.0"?>
     <chapter xml:id="community"
       version="5.0" xmlns="http://docbook.org/ns/docbook"
       xmlns:xlink="http://www.w3.org/1999/xlink"
       xmlns:xi="http://www.w3.org/2001/XInclude"
       xmlns:svg="http://www.w3.org/2000/svg"
       xmlns:m="http://www.w3.org/1998/Math/MathML"
       xmlns:html="http://www.w3.org/1999/xhtml"
       xmlns:db="http://docbook.org/ns/docbook">
 <!--
 /**
  * Licensed to the Apache Software Foundation (ASF) under one
  * or more contributor license agreements.  See the NOTICE file
  * distributed with this work for additional information
  * regarding copyright ownership.  The ASF licenses this file
  * to you under the Apache License, Version 2.0 (the
  * "License"); you may not use this file except in compliance
  * with the License.  You may obtain a copy of the License at
  *
  *     http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
 -->
     <title>Community</title>
     <section xml:id="decisions">
       <title>Decisions</title>
       <section xml:id="feature_branches">
         <title>Feature Branches</title>
         <para>Feature Branches are easy to make.  You do not have to be a committer to make one.  Just request the name of your branch be added to JIRA up on the
         developer's mailing list and a committer will add it for you.  Thereafter you can file issues against your feature branch in Apache HBase JIRA.  Your code you
         keep elsewhere -- it should be public so it can be observed -- and you can update dev mailing list on progress.   When the feature is ready for commit,
         3 +1s from committers will get your feature merged<footnote><para>See <link xlink:href="http://search-hadoop.com/m/asM982C5FkS1">HBase, mail # dev - Thoughts about large feature dev branches</link></para></footnote>
         </para>
       </section>
       <section xml:id="patchplusonepolicy">
         <title>Patch +1 Policy</title>
         <para>
 The below policy is something we put in place 09/2012.  It is a
 suggested policy rather than a hard requirement.  We want to try it
 first to see if it works before we cast it in stone.
         </para>
 <para>
 Apache HBase is made of
 <link xlink:href="https://issues.apache.org/jira/browse/HBASE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel">components</link>.
 Components have one or more <xref linkend="OWNER" />s.  See the 'Description' field on the
 <link xlink:href="https://issues.apache.org/jira/browse/HBASE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel">components</link>
 JIRA page for who the current owners are by component.
 </para>
 <para>
 Patches that fit within the scope of a single Apache HBase component require,
 at least, a +1 by one of the component's owners before commit. If
 owners are absent -- busy or otherwise -- two +1s by non-owners will
 suffice.
 </para>
 <para>
 Patches that span components need at least two +1s before they can be
 committed, preferably +1s by owners of components touched by the
 x-component patch (TODO: This needs tightening up but I think fine for
 first pass).
 </para>
 <para>
 Any -1 on a patch by anyone vetos a patch; it cannot be committed
 until the justification for the -1 is addressed.
 </para>
       </section>
       <section xml:id="hbase.fix.version.in.JIRA">
           <title>How to set fix version in JIRA on issue resolve</title>
           <para>Here is how <link xlink:href="http://search-hadoop.com/m/azemIi5RCJ1">we agreed</link> to set versions in JIRA when we
               resolve an issue.  If trunk is going to be 0.98.0 then:
               <itemizedlist>
                   <listitem><para>
               Commit only to trunk: Mark with 0.98
                 </para></listitem>
                   <listitem><para>
               Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
                 </para></listitem>
                   <listitem><para>
               Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
                 </para></listitem>
                   <listitem><para>
               Commit to 89-fb: Mark with 89-fb.
                 </para></listitem>
                   <listitem><para>
               Commit site fixes: no version
                 </para></listitem>
           </itemizedlist>
           </para>
       </section>
       <section xml:id="hbase.when.to.close.JIRA">
           <title>Policy on when to set a RESOLVED JIRA as CLOSED</title>
           <para>We <link xlink:href="http://search-hadoop.com/m/4cIKs1iwXMS1">agreed</link>
               that for issues that list multiple releases in their <emphasis>Fix Version/s</emphasis> field,
               CLOSE the issue on the release of any of the versions listed; subsequent change
               to the issue must happen in a new JIRA.
           </para>
       </section>
       <section xml:id="no.permanent.state.in.zk">
           <title>Only transient state in ZooKeeper!</title>
           <para>
 You should be able to kill the data in zookeeper and hbase should ride over it recreating the zk content as it goes.
 This is an old adage around these parts.  We just made note of it now.  We also are currently in violation of this
 basic tenet -- replication at least keeps permanent state in zk -- but we are working to undo this breaking of a
 golden rule.
           </para>
       </section>
     </section>
     <section xml:id="community.roles">
       <title>Community Roles</title>
       <section xml:id="OWNER">
           <title>Component Owner/Lieutenant</title>
         <para>
 Component owners are listed in the description field on this Apache HBase JIRA <link xlink:href="https://issues.apache.org/jira/browse/HBASE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel">components</link>
 page.  The owners are listed in the 'Description' field rather than in the 'Component
 Lead' field because the latter only allows us list one individual
 whereas it is encouraged that components have multiple owners.
         </para>
 <para>
 Owners or component lieutenants are volunteers who are (usually, but not necessarily) expert in
 their component domain and may have an agenda on how they think their
 Apache HBase component should evolve.
 </para>
 <para>
 Duties include:
 <orderedlist>
 <listitem>
 <para>
 Owners will try and review patches that land within their component's scope.
 </para>
 </listitem>
 <listitem>
 <para>
 If applicable, if an owner has an agenda, they will publish their
 goals or the design toward which they are driving their component
 </para>
 </listitem>
 </orderedlist>
 </para>
 <para>
 If you would like to be volunteer as a component owner, just write the
 dev list and we'll sign you up. Owners do not need to be committers.
 </para>
       </section>
     </section>
       <section xml:id="hbase.commit.msg.format">
           <title>Commit Message format</title>
           <para>We <link xlink:href="http://search-hadoop.com/m/Gwxwl10cFHa1">agreed</link>
           to the following SVN commit message format:
 <programlisting>HBASE-xxxxx &lt;title>. (&lt;contributor>)</programlisting>
 If the person making the commit is the contributor, leave off the '(&lt;contributor>)' element.
           </para>
       </section>
     </chapter>
	<?xml version="1.0"?>
	<chapter xml:id="community"
	version="5.0" xmlns="http://docbook.org/ns/docbook"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:m="http://www.w3.org/1998/Math/MathML"
	xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:db="http://docbook.org/ns/docbook">
	<!--
	/**
	* Licensed to the Apache Software Foundation (ASF) under one
	* or more contributor license agreements. See the NOTICE file
	* distributed with this work for additional information
	* regarding copyright ownership. The ASF licenses this file
	* to you under the Apache License, Version 2.0 (the
	* "License"); you may not use this file except in compliance
	* with the License. You may obtain a copy of the License at
	*
	* http://www.apache.org/licenses/LICENSE-2.0
	*
	* Unless required by applicable law or agreed to in writing, software
	* distributed under the License is distributed on an "AS IS" BASIS,
	* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	* See the License for the specific language governing permissions and
	* limitations under the License.
	*/
	-->
	<title>Community</title>
	<section xml:id="decisions">
	<title>Decisions</title>
	<section xml:id="feature_branches">
	<title>Feature Branches</title>
	<para>Feature Branches are easy to make. You do not have to be a committer to make one. Just request the name of your branch be added to JIRA up on the
	developer's mailing list and a committer will add it for you. Thereafter you can file issues against your feature branch in Apache HBase JIRA. Your code you
	keep elsewhere -- it should be public so it can be observed -- and you can update dev mailing list on progress. When the feature is ready for commit,
	3 +1s from committers will get your feature merged<footnote><para>See <link xlink:href="http://search-hadoop.com/m/asM982C5FkS1">HBase, mail # dev - Thoughts about large feature dev branches</link></para></footnote>
	</para>
	</section>
	<section xml:id="patchplusonepolicy">
	<title>Patch +1 Policy</title>
	<para>
	The below policy is something we put in place 09/2012. It is a
	suggested policy rather than a hard requirement. We want to try it
	first to see if it works before we cast it in stone.
	</para>
	<para>
	Apache HBase is made of
	<link xlink:href="https://issues.apache.org/jira/browse/HBASE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel">components</link>.
	Components have one or more <xref linkend="OWNER" />s. See the 'Description' field on the
	<link xlink:href="https://issues.apache.org/jira/browse/HBASE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel">components</link>
	JIRA page for who the current owners are by component.
	</para>
	<para>
	Patches that fit within the scope of a single Apache HBase component require,
	at least, a +1 by one of the component's owners before commit. If
	owners are absent -- busy or otherwise -- two +1s by non-owners will
	suffice.
	</para>
	<para>
	Patches that span components need at least two +1s before they can be
	committed, preferably +1s by owners of components touched by the
	x-component patch (TODO: This needs tightening up but I think fine for
	first pass).
	</para>
	<para>
	Any -1 on a patch by anyone vetos a patch; it cannot be committed
	until the justification for the -1 is addressed.
	</para>
	</section>
	<section xml:id="hbase.fix.version.in.JIRA">
	<title>How to set fix version in JIRA on issue resolve</title>
	<para>Here is how <link xlink:href="http://search-hadoop.com/m/azemIi5RCJ1">we agreed</link> to set versions in JIRA when we
	resolve an issue. If trunk is going to be 0.98.0 then:
	<itemizedlist>
	<listitem><para>
	Commit only to trunk: Mark with 0.98
	</para></listitem>
	<listitem><para>
	Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
	</para></listitem>
	<listitem><para>
	Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
	</para></listitem>
	<listitem><para>
	Commit to 89-fb: Mark with 89-fb.
	</para></listitem>
	<listitem><para>
	Commit site fixes: no version
	</para></listitem>
	</itemizedlist>
	</para>
	</section>
	<section xml:id="hbase.when.to.close.JIRA">
	<title>Policy on when to set a RESOLVED JIRA as CLOSED</title>
	<para>We <link xlink:href="http://search-hadoop.com/m/4cIKs1iwXMS1">agreed</link>
	that for issues that list multiple releases in their <emphasis>Fix Version/s</emphasis> field,
	CLOSE the issue on the release of any of the versions listed; subsequent change
	to the issue must happen in a new JIRA.
	</para>
	</section>
	<section xml:id="no.permanent.state.in.zk">
	<title>Only transient state in ZooKeeper!</title>
	<para>
	You should be able to kill the data in zookeeper and hbase should ride over it recreating the zk content as it goes.
	This is an old adage around these parts. We just made note of it now. We also are currently in violation of this
	basic tenet -- replication at least keeps permanent state in zk -- but we are working to undo this breaking of a
	golden rule.
	</para>
	</section>
	</section>
	<section xml:id="community.roles">
	<title>Community Roles</title>
	<section xml:id="OWNER">
	<title>Component Owner/Lieutenant</title>
	<para>
	Component owners are listed in the description field on this Apache HBase JIRA <link xlink:href="https://issues.apache.org/jira/browse/HBASE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel">components</link>
	page. The owners are listed in the 'Description' field rather than in the 'Component
	Lead' field because the latter only allows us list one individual
	whereas it is encouraged that components have multiple owners.
	</para>
	<para>
	Owners or component lieutenants are volunteers who are (usually, but not necessarily) expert in
	their component domain and may have an agenda on how they think their
	Apache HBase component should evolve.
	</para>
	<para>
	Duties include:
	<orderedlist>
	<listitem>
	<para>
	Owners will try and review patches that land within their component's scope.
	</para>
	</listitem>
	<listitem>
	<para>
	If applicable, if an owner has an agenda, they will publish their
	goals or the design toward which they are driving their component
	</para>
	</listitem>
	</orderedlist>
	</para>
	<para>
	If you would like to be volunteer as a component owner, just write the
	dev list and we'll sign you up. Owners do not need to be committers.
	</para>
	</section>
	</section>
	<section xml:id="hbase.commit.msg.format">
	<title>Commit Message format</title>
	<para>We <link xlink:href="http://search-hadoop.com/m/Gwxwl10cFHa1">agreed</link>
	to the following SVN commit message format:
	<programlisting>HBASE-xxxxx <title>. (<contributor>)</programlisting>
	If the person making the commit is the contributor, leave off the '(<contributor>)' element.
	</para>
	</section>
	</chapter>