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