Chapter 1. Community

Table of Contents

1.1. Decisions
1.1.1. Feature Branches
1.1.2. Patch +1 Policy
1.1.3. How to set fix version in JIRA on issue resolve
1.1.4. Policy on when to set a RESOLVED JIRA as CLOSED
1.2. Community Roles
1.2.1. Component Owner/Lieutenant

1.1. Decisions

1.1.1. Feature Branches

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[1]

1.1.2. Patch +1 Policy

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.

Apache HBase is made of components. Components have one or more Section 1.2.1, “Component Owner/Lieutenant”s. See the 'Description' field on the components JIRA page for who the current owners are by component.

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.

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).

Any -1 on a patch by anyone vetos a patch; it cannot be committed until the justification for the -1 is addressed.

1.1.3. How to set fix version in JIRA on issue resolve

Here is how we agreed to set versions in JIRA when we resolve an issue. If trunk is going to be 0.98.0 then:

  • Commit only to trunk: Mark with 0.98

  • Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x

  • Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x

  • Commit to 89-fb: Mark with 89-fb.

  • Commit site fixes: no version

1.1.4. Policy on when to set a RESOLVED JIRA as CLOSED

We agreed that for issues that list multiple releases in their Fix Version/s field, CLOSE the issue on the release of any of the versions listed; subsequent change to the issue must happen in a new JIRA.

1.2. Community Roles

1.2.1. Component Owner/Lieutenant

Component owners are listed in the description field on this Apache HBase JIRA components 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.

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.

Duties include:

  1. Owners will try and review patches that land within their component's scope.

  2. If applicable, if an owner has an agenda, they will publish their goals or the design toward which they are driving their component

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.

comments powered by Disqus