hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Misty Stanley-Jones (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4593) Design and document the official procedure for posting patches, commits, commit messages, etc. to smooth process and make integration with tools easier
Date Wed, 16 Jul 2014 02:35:04 GMT

    [ https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14063018#comment-14063018

Misty Stanley-Jones commented on HBASE-4593:

It has been a few years. Do we have any consensus on this? Here is what I have learned so
far (lots by trial and error):

Code Conventions:
* Spaces, not tabs -- 2 spaces per indentation
* 100-character line length
* Opening brackets NOT on a newline: 
public RegionException() {
* I think there are some rules that if you introduce code you are supposed to introduce tests,
and there is some check for @author tags or something. Maybe someone can clue me in.

Workflow (non-committer):
* Assign JIRA to self
* Create a new git branch from master: git checkout -b HBASE-XXXX
* Do all work for the issue. Test that you didn't break anything by running "mvn clean install
-Dskiptests" or, in the case of documentation or website changes "mvn clean site -Dskiptests"
* Before making a patch, make sure to rebase and resolve any conflicts: git rebase origin/master
* Save your changes to a patch: git diff --no-prefix origin/master > HBASE-XXXX.patch
* Attach patch file to JIRA, along with supplemental files such as images / screenshots.
* Click Submit Patch, wait for review.
* If more revisions need to be made, make them in your branch and make a new patch against
origin/master called HBASE-XXXX-<revision>.patch, attach it to the JIRA too.
* Commit messages don't seem to matter for a non-committer

Workflow (committer):
[~stack] or other, please fill in the blanks here, as far as workflow, review rules, commit
message format etc
* Commit messages seem to start with the JIRA ID and then have a sentence describing the change,
such as: "HBASE-11489 ClassNotFoundException while running IT tests in trunk using 'mvn verify'
(Ram)" -- are there any length limits? Is it a rule of thumb that the JIRA title should be

> Design and document the official procedure for posting patches, commits, commit messages,
etc. to smooth process and make integration with tools easier
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: HBASE-4593
>                 URL: https://issues.apache.org/jira/browse/HBASE-4593
>             Project: HBase
>          Issue Type: Task
>          Components: documentation
>            Reporter: Jonathan Gray
> I have been building a tool (currently called reposync) to help me keep the internal
FB hbase-92-based branch up-to-date with the public branches.
> Various inconsistencies in our process has made it difficult to automate a lot of this
> I'd like to work with everyone to come up with the official best practices and stick
to it.
> I welcome all suggestions.  Among some of the things I'd like to nail down:
> - Commit message format
> - Best practice and commit message format for multiple commits
> - Multiple commits per jira vs. jira per commit, what are the exceptions and when
> - Affects vs. Fix versions
> - Potential usage of [tags] in commit messages for things like book, scripts, shell...
maybe even whatever is in the components field?
> - Increased usage of JIRA tags or labels to mark exactly which repos a JIRA has been
committed to (potentially even internal repos?  ways for a tool to keep track in JIRA?)
> We also need to be more strict about some things if we want to follow Apache guidelines.
 For example, all final versions of a patch must be attached to JIRA so that the author properly
assigns it to Apache.

This message was sent by Atlassian JIRA

View raw message