[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

2014-08-25 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14109983#comment-14109983
 ] 

Hudson commented on HBASE-4593:
---

FAILURE: Integrated in HBase-TRUNK #5427 (See 
[https://builds.apache.org/job/HBase-TRUNK/5427/])
HBASE-4593 Design and document the official procedure for posting patches, 
commits, commit messages, etc. to smooth process and make integration with 
tools easier (Misty Stanley-Jones) (stack: rev 
33928f85f2b699ff3357a197b05e210048048570)
* src/main/docbkx/developer.xml
* src/main/docbkx/book.xml
HBASE-4593 Design and document the official procedure for posting patches, 
commits, commit messages, etc. to smooth process and make integration with 
tools easier (Misty Stanley-Jones) (stack: rev 
fefa4a3079af4e8d5d169a0ba1f99693a4964256)
* src/main/docbkx/unit_testing.xml


 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
Assignee: Misty Stanley-Jones
 Fix For: 2.0.0

 Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, 
 HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch, 
 HBASE-4593.patch, HBASE-4593.patch, HBASE_4593.patch


 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 stuff.
 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
(v6.2#6252)


[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

2014-08-21 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105946#comment-14105946
 ] 

Sean Busbey commented on HBASE-4593:


{noformat}
+section xml:id=build.snappy
+titleBuilding in snappy compression support/title
+paraPass code-Psnappy/code to trigger the 
codesnappy/code maven profile
+for building Google Snappy native libraries into HBase. 
See also xref
+linkend=snappy.compression//para
+/section
{noformat}

I noticed this while working on HBASE-6189. There is no profile named snappy. 
there's a profile named hadoop-snappy that is activated if you pass a 
property named snappy.

Also the xref should link to snappy.compression.installation. the one given 
doesn't exist.

 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
Assignee: Misty Stanley-Jones
 Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, 
 HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch, 
 HBASE-4593.patch, HBASE-4593.patch


 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 stuff.
 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
(v6.2#6252)


[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

2014-08-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106439#comment-14106439
 ] 

Hadoop QA commented on HBASE-4593:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12663543/HBASE_4593.patch
  against trunk revision .
  ATTACHMENT ID: 12663543

{color:red}-1 @author{color}.  The patch appears to contain 2 @author tags 
which the Hadoop community has agreed to not allow in code contributions.

{color:green}+1 tests included{color}.  The patch appears to include 2 new 
or modified tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 6 
warning messages.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+link 
xlink:href=http://hbase.apache.org/mail-lists.html;mailing lists/link page.
+There are varying levels of experience on both lists so 
patience and politeness are encouraged (and please
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+programlisting language=bournemvn clean install 
-DskipTests/programlisting
+
xlink:href=http://michaelmorello.blogspot.com/2011/09/hbase-subversion-eclipse-windows.html;
+paraYou can set up IntelliJ IDEA for similar functinoality as 
Eclipse. Follow these steps./para
+HBase code formatter described in xref 
linkend=eclipse.code.formatting /./para
+screenmvn -DskipTests clean install amp;amp; mvn 
-DskipTests package assembly:single/screen
+
filenamehbase-assembly/target/hbase-replaceablelt;versiongt;/replaceable-bin.tar.gz/filename./para

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 

 {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s): 

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10525//console

This message is automatically generated.

 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
Assignee: Misty Stanley-Jones
 Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, 
 HBASE-4593.patch, HBASE-4593.patch, 

[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

2014-08-20 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103982#comment-14103982
 ] 

Sean Busbey commented on HBASE-4593:


+1 LGTM, modulo nits below.

{noformat}
+listitem xml:id=submitting.patches.naming
+paraThe patch should have the JIRA ID in the name. 
If you generating from
+a branch, include the target branch in the 
filename. A common naming
+scheme for patches is:/para
{noformat}

If you are generating

{noformat}
+multiple attachments with the same name. However, 
at times it is easier
+to refer to different version of a patch if you add
+literal_vX/literal, where the 
replaceableX/replaceable is
+the version (starting with 2)./para
{noformat}

In the name formatting section we say to use -vX and here we say _vX. They 
should be consistent. I believe -vX is what people are currently doing.

 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
Assignee: Misty Stanley-Jones
 Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, 
 HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch, 
 HBASE-4593.patch


 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 stuff.
 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
(v6.2#6252)


[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

2014-08-20 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14104945#comment-14104945
 ] 

Hadoop QA commented on HBASE-4593:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12663220/HBASE-4593.patch
  against trunk revision .
  ATTACHMENT ID: 12663220

{color:red}-1 @author{color}.  The patch appears to contain 2 @author tags 
which the Hadoop community has agreed to not allow in code contributions.

{color:green}+1 tests included{color}.  The patch appears to include 2 new 
or modified tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 7 
warning messages.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+link 
xlink:href=http://hbase.apache.org/mail-lists.html;mailing lists/link page.
+There are varying levels of experience on both lists so 
patience and politeness are encouraged (and please
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+programlisting language=bournemvn clean install 
-DskipTests/programlisting
+
xlink:href=http://michaelmorello.blogspot.com/2011/09/hbase-subversion-eclipse-windows.html;
+paraYou can set up IntelliJ IDEA for similar functinoality as 
Eclipse. Follow these steps./para
+HBase code formatter described in xref 
linkend=eclipse.code.formatting /./para
+screenmvn -DskipTests clean install amp;amp; mvn 
-DskipTests package assembly:single/screen
+
filenamehbase-assembly/target/hbase-replaceablelt;versiongt;/replaceable-bin.tar.gz/filename./para

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
   org.apache.hadoop.hbase.TestRegionRebalancing
  org.apache.hadoop.hbase.regionserver.TestEncryptionKeyRotation

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10512//console

This message is automatically generated.

 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
Assignee: Misty Stanley-Jones
 Attachments: Chapter_18_and_19.pdf, 

[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

2014-08-14 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14098117#comment-14098117
 ] 

Hadoop QA commented on HBASE-4593:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12661939/HBASE-4593.patch
  against trunk revision .
  ATTACHMENT ID: 12661939

{color:red}-1 @author{color}.  The patch appears to contain 2 @author tags 
which the Hadoop community has agreed to not allow in code contributions.

{color:green}+1 tests included{color}.  The patch appears to include 2 new 
or modified tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+link 
xlink:href=http://hbase.apache.org/mail-lists.html;mailing lists/link page.
+There are varying levels of experience on both lists so 
patience and politeness are encouraged (and please
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+programlisting language=bournemvn clean install 
-DskipTests/programlisting
+
xlink:href=http://michaelmorello.blogspot.com/2011/09/hbase-subversion-eclipse-windows.html;
+screenmvn -DskipTests clean install amp;amp; mvn 
-DskipTests package assembly:single/screen
+
filenamehbase-assembly/target/hbase-replaceablelt;versiongt;/replaceable-bin.tar.gz/filename./para
+programlisting language=xml![CDATA[settings 
xmlns=http://maven.apache.org/SETTINGS/1.0.0;
+titleUpdate the filenameCHANGES.txt/filename file 
and the POM files./title

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10444//console

This message is automatically generated.

 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
Assignee: Misty Stanley-Jones
 Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, 
 HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch


 I have been building a tool (currently called reposync) to help 

[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

2014-08-13 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095567#comment-14095567
 ] 

Sean Busbey commented on HBASE-4593:


Overall, LGTM. Couple of minor adjustments below:

{noformat}
+section xml:id=maven.build.commands.unitall
+titleRunning all or individual Unit Tests/title
+paraSee the xref linkend=hbase.unittests.cmds/ section 
above in xref
+linkend=hbase.unittests//para
+/section
{noformat}

This is in 18.4.1.2 now, and unit tests are now in 18.9.2/3, so this should be 
below rather than above. Also, it looks like running tests is no longer a 
subsection of unittests, so this may need to be rephrased.

{noformat}
+titleReleasing Apache HBase/title
+formalpara
+titleBuilding against HBase 1.x/title
+paraHBase 1.x requires Java 7 to build. See xref 
linkend=java/ for Java
+requirements per HBase release./para
+/formalpara
{noformat}

Is this meant to be a note callout?

{noformat}
+section xml:id=common.patch.feedback
+titleCode Formatting Conventions/title
{noformat}

The entries in here end up at section-depth 5. Would this read better if we 
moved all of them up into Code Standards? They'd be at section-depth 4, and we 
could just add a sentence to the intro on contributing patches that says make 
sure you follow the code standards with a link.

 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
Assignee: Misty Stanley-Jones
 Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, 
 HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch


 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 stuff.
 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
(v6.2#6252)


[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

2014-08-13 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095573#comment-14095573
 ] 

Sean Busbey commented on HBASE-4593:


{noformat}
+listitem
+paraIf you need to submit yuor patch against 
multiple branches, rather
+than just master, name each version of the patch 
with the branch it is
+for, following the naming conventions in xref
+linkend=submitting.patches.create/./para
{noformat}

typo: yuor - your

 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
Assignee: Misty Stanley-Jones
 Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, 
 HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch


 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 stuff.
 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
(v6.2#6252)


[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

2014-08-10 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092315#comment-14092315
 ] 

Hadoop QA commented on HBASE-4593:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12660885/HBASE-4593.patch
  against trunk revision .
  ATTACHMENT ID: 12660885

{color:red}-1 @author{color}.  The patch appears to contain 2 @author tags 
which the Hadoop community has agreed to not allow in code contributions.

{color:green}+1 tests included{color}.  The patch appears to include 2 new 
or modified tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+link 
xlink:href=http://hbase.apache.org/mail-lists.html;mailing lists/link page.
+There are varying levels of experience on both lists so 
patience and politeness are encouraged (and please
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+programlisting language=bournemvn clean install 
-DskipTests/programlisting
+
xlink:href=http://michaelmorello.blogspot.com/2011/09/hbase-subversion-eclipse-windows.html;
+screenmvn -DskipTests clean install amp;amp; mvn 
-DskipTests package assembly:single/screen
+
filenamehbase-assembly/target/hbase-replaceablelt;versiongt;/replaceable-bin.tar.gz/filename./para
+programlisting language=xml![CDATA[settings 
xmlns=http://maven.apache.org/SETTINGS/1.0.0;
+titleUpdate the filenameCHANGES.txt/filename file 
and the POM files./title

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 

 {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s): 

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10372//console

This message is automatically generated.

 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
Assignee: Misty Stanley-Jones
 Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, 
 HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch



[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

2014-08-07 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088974#comment-14088974
 ] 

Hadoop QA commented on HBASE-4593:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12660324/HBASE-4593.patch
  against trunk revision .
  ATTACHMENT ID: 12660324

{color:red}-1 @author{color}.  The patch appears to contain 2 @author tags 
which the Hadoop community has agreed to not allow in code contributions.

{color:green}+1 tests included{color}.  The patch appears to include 2 new 
or modified tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+programlisting language=bournemvn clean install 
-DskipTests/programlisting
+
xlink:href=http://michaelmorello.blogspot.com/2011/09/hbase-subversion-eclipse-windows.html;
+programlisting language=xml![CDATA[settings 
xmlns=http://maven.apache.org/SETTINGS/1.0.0;
+$ MAVEN_OPTS=-Xmx2g mvn clean install -DskipTests assembly:single 
-Dassembly.file=hbase-assembly/src/main/assembly/src.xml -Prelease
+ $ MAVEN_OPTS=-Xmx3g mvn clean install -DskipTests  javadoc:aggregate site 
assembly:single -Prelease
+
filenamehttps://svn.apache.org/repos/asf/hbase/hbase.apache.org/trunk/filename.
+
xlink:href=http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html;
+
classnameorg.apache.hadoop.hbase.chaos.factories.MonkeyConstants/classname
+
xlink:href=http://blog.cloudera.com/blog/2013/09/how-to-test-hbase-applications-using-popular-tools/;

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
   org.apache.hadoop.hbase.TestRegionRebalancing

 {color:red}-1 core zombie tests{color}.  There are 3 zombie test(s): 

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/10335//console

This message is automatically generated.

 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
Assignee: Misty Stanley-Jones
 Attachments: HBASE-4593.patch, HBASE-4593.pdf


 I have been 

[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

2014-08-07 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089273#comment-14089273
 ] 

Sean Busbey commented on HBASE-4593:


There are a few places in the rendered PDF where it looks like spacing is 
missing between plain text and formatted (e.g. links, monospace). It looks like 
there are spaces in the source patch though, so probably a rendering artifact?

What's the difference between section 18.1 and 18.10? they seem to be aimed at 
the same thing. If they're not, 18.1 should have a pointer to 18.10.

{quote}
+para If you are looking to contribute to Apache HBase, look for 
issues in JIRA tagged with
+the label 'beginner': link
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+project = HBASE AND labels in (beginner)/link. These are 
issues HBase

{quote}

personally, I think using issues in JIRA tagged with the label 'beginner' as 
teh link text (instead of the jira query text) makes the section read clearer.

{quote}
+link xlink:href=http://git.apache.org/;Apache Git/link 
page. /para
{quote}

nit: trailing whitespace between '.' and end of paragraph.


{quote}
+section
+titleOther IDEs/title
+paraTODO - Please contribute/para
 /section
{quote}

Can we make this more specific or leave it out? Ideally a follow-on umbrella 
jira that we can reference here. for subtasks of that umbrella, I know IntelliJ 
is popular with the IDE users I talk to.

{quote}
+codecompile-protobuf/code to do this./para
+programlisting language=bournemvn compile 
-Dcompile-protobuf/programlisting
+programlisting language=bournemvn compile 
-Pcompile-protobuf/programlisting
{quote}

This looks like I need to run both of these commands to rebuild the protobufs. 
I believe I only need to run one of them. We should pick which one is preferred 
and only suggest that one.

The protoc.path example looks like we prefer the -Dcompile-protobuf version. 
I'm pretty sure the idiomatic way for maven is the profile, so perhaps we 
should make both use that?

{quote}
+section xml:id=build.snappy
+titleBuilding in snappy compression support/title
+paraPass code-Dsnappy/code to trigger the 
codesnappy/code maven profile for
+building Google Snappy native libraries into HBase. See also 
xref
+linkend=snappy.compression//para
{quote}

Similar to the protobuf bit, can we change this to use the profile directly?

{quote}
+paraHBase 0.96.x will run on Hadoop 1.x or Hadoop 2.x. HBase 
0.98 still runs on both,
+but HBase 0.98 deprecates use of Hadoop 1. HBase 1.x will 
emphasisnot/emphasis
+run on Hadoop 1. In the following procedures, we make a 
distinction between HBase
+1.x builds and the awkward process involved building HBase 
0.96/0.98 for either
+Hadoop 1 or Hadoop 2 targets. /para
{quote}

Maybe end with a link to the java ref for more info?


{quote}
+formalpara
+titleMaven Version/title
+paraYou must use maven 3.0.x (Check by running commandmvn 
-version/command).
 /para
+/formalpara
{quote}

Is this generally true? Should we add it to the section on basic compilation? 
Seems more likely to trip up a new person trying to build than someone creating 
a release candidate.

{quote}
+titleBefore You Begin/title
+paraBefore you make a release candidate, do a practise run 
by deploying a
{quote}

Do we have a documentation style guide that covers British v American english 
usage?

{quote}
+intervention is needed here), the checking of the produced 
artifacts to ensure
+they are 'good' -- e.g. undoing the produced tarballs, 
eyeballing them to make
+sure they look right then starting and checking all is 
running properly -- and
{quote}

unpacking would be clearer than undoing

{quote}
+titleIf you used the filenamemake_rc.sh/filename 
script instead of doing
+the above manually,, do your sanity checks now./title
{quote}

nit: extraneous comma.

{quote}
+docbkx:generate-html/command (TODO: It looks like you have 
to run commandmvn
+site/command first because docbkx wants to include a 
transformed
+filenamehbase-default.xml/filename. Fix). When you run mvn 
site, we do the
{quote}

Can we make a jira for this and then reference it here?

{quote}
+section xml:id=hbase.rc.voting
+titleVoting on Release Candidates/title
+para Everyone is encouraged to try and vote on HBase release 
candidates. 

[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

2014-08-07 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090151#comment-14090151
 ] 

Andrew Purtell commented on HBASE-4593:
---

Fantastic draft!

In addition to Sean's comments above:

---

In 18.4. Building Apache HBase, we should also describe a developer can build 
themselves a tarball without going through the whole release procedure. I use
{noformat}
mvn -DskipTests clean install  mvn -DskipTests package assembly:single
{noformat}
The distribution tarball can be found at 
{{hbase-assembly/target/hbase-version-bin.tar.gz}}

---

Procedure 18.2. Release Procedure, step 1 says Update the CHANGES.txt file 
but this is also about updating POMs as well as CHANGES.txt.

---

Elsewhere in the release procedure instructions, the 'MAVEN_OPTS=-Xmx3g' 
appearing in example commands is an artifact of a Mac OS X environment. This 
isn't needed on Linux in my experience. We could remove the MAVEN_OPTS here and 
put in a footnote instead.

---

In 18.12.1. Create Patch, If you need to revise your patch, leave the previous 
patch file(s) attached to the JIRA, and upload the new one with a revision ID.

This isn't strictly necessary. JIRA will sort files with the same name 
descending by date. 

---

18.12.2. Unit Tests

Perhaps after this add a section 'Integration Tests'. 

Significant new features should provide an integration test in addition to 
unit tests, suitable for exercising the new feature at different points in its 
configuration space. Or something like that?

---

Will make another pass later. So much material.

 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
Assignee: Misty Stanley-Jones
 Attachments: HBASE-4593.patch, HBASE-4593.pdf


 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 stuff.
 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
(v6.2#6252)


[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

2014-08-07 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090324#comment-14090324
 ] 

Sean Busbey commented on HBASE-4593:


{quote}
+section xml:id=jira
+titleJira/title
+paraCheck for existing issues in link
+
xlink:href=https://issues.apache.org/jira/browse/HBASE;Jira/link. If it's
+either a new feature request, enhancement, or a bug, file a 
ticket. /para
+paraTo check for existing issues which you can tackle as a 
beginner, search for link
+
xlink:href=https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
+issues in JIRA tagged with the label 'beginner'/link. 
See xref
+linkend=getting.involved/ for more information./para
{quote}

Now that this is 18.1.3, referring back to 18.1 doesn't make much sense.

{quote}
 section xml:id=maven.build.commands
titleMaven Build Commands/title
@@ -1061,18 +1317,18 @@ batch.restart.rs.ratio=0.4f
/para
paraNote: use Maven 3 (Maven 2 may work but we suggest you use Maven 
3).
/para
-   section xml:id=maven.build.commands.compile
+   example xml:id=maven.build.commands.compile
   titleCompile/title
   programlisting language=bourne
 mvn compile
   /programlisting
-   /section
+   /example
 
-   section xml:id=maven.build.commands.unitall
+   formalpara xml:id=maven.build.commands.unitall
   titleRunning all or individual Unit Tests/title
   paraSee the xref linkend=hbase.unittests.cmds / section
   above in xref linkend=hbase.unittests //para
-   /section
+   /formalpara
 
section xml:id=maven.build.hadoop
   titleBuilding against various hadoop versions./title
{quote}

With the current layout, it looks like 18.10.1 can be moved under 18.4. With it 
there, the intro to 18.10 can be dropped. Also the reference to 18.10 that's in 
18.4.1 (esp since there is more info about different maven commands in 18.4 
than 18.10).

{quote}
+paraIf you need to revise your patch, leave the previous 
patch file(s)
+attached to the JIRA, and upload the new one, as in 
xref
+linkend=submitting.patches.naming/. Cancel the 
Patch Available flag
+and then re-trigger it, by toggling the 
guibuttonPatch
+Available/guibutton button in JIRA. JIRA sorts 
attached files by the
+time they were attached, and has no problem with 
multiple attachments with
+the same name./para
+/listitem
+listitem
+paraIf you need to submit yuor patch against multiple 
branches, rather than
+just master, name each version of the patch with the 
branch it is for, as in
+xref linkend=submitting.patches.naming/./para
{quote}

the links to submitting.patches.naming show up as ???. Are list items 
reference-able or is this a rendering problem?

{quote}
+  example xml:id=common.patch.feedback.space.invaders
 titleSpace Invaders/title
-paraRather than do this...
+paraDo not use extra spaces around brackets. Use the second 
style, rather than the
+first./para
{quote}

Why do these start as examples and then turn into sections? For example, the 
example on autogenerated code is similar in scope and presentation as the 
section for useless javadocs.

We should make them all one or the other. I'd favor sections, but we're already 
deeply nested.

{quote}
+section xml:id=common.patch.feedback.writable
+titleImplementing Writable/title
+note
+titleApplies pre-0.96 only/title
+paraIn 0.96, HBase moved to protocol buffers 
(protobufs). The below section on
+Writables applies to 0.94.x and previous, not to 0.96 
and beyond. /para
+/note
+paraEvery class returned by RegionServers must implement the 
codeWritable/code
+interface. If you are creating a new class that needs to 
implement this
+interface, do not forget the default constructor. /para
+/section
{quote}
Since this example is only for some branches, it should probably go after all 
the other guidelines.

{quote}
+guilabelReview Group/guilabel. If you fill in 
the
+guilabelBugs/guilabel field, the review board 
is attached to the
+relevant JIRA automatically. The more fields you fill 
in, the better. Click
{quote}

I don't think this is true. 

[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

2014-08-06 Thread Misty Stanley-Jones (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088291#comment-14088291
 ] 

Misty Stanley-Jones commented on HBASE-4593:


From an email from [~apurtell] 
{code}
-- Forwarded message --
From: Andrew Purtell apurt...@apache.org
Date: Fri, Aug 1, 2014 at 10:32 AM
Subject: Friendly reminder to use git cherry-pick and git rebase instead of git 
merge
To: d...@hbase.apache.org d...@hbase.apache.org


We previously agreed to avoid merge commits appearing in our git history.

Found a merge commit on 0.98 branch.

Thanks!
{code}

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-06 Thread Misty Stanley-Jones (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088293#comment-14088293
 ] 

Misty Stanley-Jones commented on HBASE-4593:


What about ReviewBoard? Can we do better than 
http://hbase.apache.org/book.html#reviewboard? What is larger patches? Can 
someone describe the workflow of ReviewBoard for me? I have never used it.

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-06 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088301#comment-14088301
 ] 

Sean Busbey commented on HBASE-4593:


My own heuristic is if a patch will fit on a single screen (of my 204x60 vim 
session) then I just attach it as is. Otherwise I put it on reviewboard.

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-06 Thread Misty Stanley-Jones (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088322#comment-14088322
 ] 

Misty Stanley-Jones commented on HBASE-4593:


Most of my patches are longer than that, due to the nature of Docbook. However, 
I don't think most people benefit much from reviewing the XML itself -- I 
should probably just be attaching PDF renders for review, but have been too 
lazy. At least the patches show you what has changed, quickly. A render would 
force you to spot the changes, unless I mark them up in some way (which I can 
do). How do the committers prefer to review docs?

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-06 Thread Alex Newman (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088325#comment-14088325
 ] 

Alex Newman commented on HBASE-4593:


Right! I think docs only changes can be exempt from review board IMHO.

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-06 Thread Misty Stanley-Jones (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088375#comment-14088375
 ] 

Misty Stanley-Jones commented on HBASE-4593:


I played around with git format-patch, but it seems to force you to only commit 
once per branch, otherwise it will generate multiple files, and we have said 
that we want only a single file per JIRA. Am I missing a way to make git 
format-patch only generate a single file, or are you guys just using git stash 
instead of git commit, until the very end? And how do you handle small changes 
due to feedback?

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-06 Thread Alex Newman (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088384#comment-14088384
 ] 

Alex Newman commented on HBASE-4593:


I run git diff --no-prefix origin/master

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-06 Thread Nick Dimiduk (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14088457#comment-14088457
 ] 

Nick Dimiduk commented on HBASE-4593:
-

bq. Am I missing a way to make git format-patch only generate a single file 

I squish all my local commits into one before attaching to JIRA.

bq. And how do you handle small changes due to feedback?

This results in N more commits that just get squished again before I post the 
next patch version. I also tend to rebased onto master and rerun tests locally 
with each new patch, to stay up-to-date and increase the odds of buildbot not 
having issues.

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-01 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082576#comment-14082576
 ] 

stack commented on HBASE-4593:
--

[~misty] Seems like no-prefix still needed if patch applied with patch command. 
 I like what [~mdrob] suggests though especially if the author does a nice job 
with the commit message as we're seeing from [~busbey] lately and as has the 
likes of [~ndimiduk] have done always; its a shame dropping their nice work 
composing a fat commit message on the floor.  Let me take discussion to the 
list.

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-01 Thread Nick Dimiduk (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082997#comment-14082997
 ] 

Nick Dimiduk commented on HBASE-4593:
-

bq. Save your changes to a patch: git diff --no-prefix origin/master  
HBASE-.patch

I work off of local feature branches, thus I use {{git format-patch HEAD~1}} to 
generate my patches. This is how my commit messages come along for the ride. 
Buildbot appears to have no issue with this formatting.

Title of commit message by convention is something along the lines of
{noformat}
jira-id jira-title (contributor-name-if-not-commit-author)
{noformat}

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-01 Thread Nick Dimiduk (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082999#comment-14082999
 ] 

Nick Dimiduk commented on HBASE-4593:
-

I should add, re: commit message title. There is some convention around 
additional '.' or ':' used by other Hadoop projects, but we HBase appear to 
have not picked up the habit.

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-08-01 Thread Alex Newman (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083100#comment-14083100
 ] 

Alex Newman commented on HBASE-4593:


Maybe this is the wrong time to suggest it. But i feel like we have a ton of 
nits in HBase. Perhaps now we could enshrine a policy to avoid this. Like 
whenever you touch a file, you post a separate patch where you handle weird 
formatting nits, spelling errors, etc. That way no one has to really review it 
carefully (as it is just autodetected nits), and the two patches can go in 
together. 



 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-07-31 Thread Misty Stanley-Jones (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14081868#comment-14081868
 ] 

Misty Stanley-Jones commented on HBASE-4593:


Some of this done in HBASE-11539. 

[~md...@cloudera.com] it seems like for a while the --no-prefix wasn't needed 
but then it was needed again. I haven't tried leaving it off again because it 
was breaking the patches. Can you verify it's no longer needed?

I don't really mind what the process is that we use -- that is up to the HBase 
committers. I'll just say whatever they tell me. :)

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-07-16 Thread Mike Drob (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063440#comment-14063440
 ] 

Mike Drob commented on HBASE-4593:
--

bq. Save your changes to a patch: git diff --no-prefix origin/master  
HBASE-.patch
This changed recently, and should be just {{git diff origin/master  
HBASE-.patch}}

I've seen other projects prefer naming patches as {{PROJECT-XXX.patch.txt}} 
because that means the patch will open in browser instead of prompting for a 
download.

Over on Accumulo, we suggest to folks that they commit locally and then do 
{{git format-patch --stdout}} instead of git diff because it preserves the 
authorship and commit message. Of course, committers would need to apply it 
using {{git am}} or {{git am --signoff}}. YMMV.

 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
Assignee: Misty Stanley-Jones

 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 stuff.
 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
(v6.2#6252)


[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

2014-07-15 Thread Misty Stanley-Jones (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: 
{code}
public RegionException() {
  super();
}
{code}
* 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-
* 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-.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--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 used?

 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 stuff.
 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
(v6.2#6252)


[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

2011-10-14 Thread Jonathan Gray (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128012#comment-13128012
 ] 

Jonathan Gray commented on HBASE-4593:
--

BTW, once we nail down the formatting and everything, I will toss reposync up 
on a github repo or something.

 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 stuff.
 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[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

2011-10-14 Thread stack (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128075#comment-13128075
 ] 

stack commented on HBASE-4593:
--

Good stuff Jon.  I started to make a response and then thought, back and forth 
on this should probably be out on the dev list?  Want to start a thread?

 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 stuff.
 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira