Re: [VOTE] Release Apache Cassandra 2.2.0-rc2
+1 non-binding On 07/06/2015 01:47 PM, Jake Luciani wrote: I propose the following artifacts for release as 2.2.0-rc2. sha1: ebc50d783505854f04f183297ad3009b9095b07e Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.0-rc2-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1065/org/apache/cassandra/apache-cassandra/2.2.0-rc2/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1065/ The artifacts as well as the debian package are also available here: http://people.apache.org/~jake The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/C1QdHh (CHANGES.txt) [2]: http://goo.gl/NPABEq (NEWS.txt)
Re: [VOTE] Release Apache Cassandra 2.1.8
+1 non-binding On 07/06/2015 12:04 PM, Jake Luciani wrote: I propose the following artifacts for release as 2.1.8. sha1: db39257c34152f6ccf8d53784cea580dbfe1edad Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.8-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1063/org/apache/cassandra/apache-cassandra/2.1.8/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1063/ The artifacts as well as the debian package are also available here: http://people.apache.org/~jake The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/BFYiEO (CHANGES.txt) [2]: http://goo.gl/24XaPp (NEWS.txt)
Re: [VOTE] Release Apache Cassandra 2.2.0-rc2
-1. I've found some problems with 2.2 commit log replay in https://issues.apache.org/jira/browse/CASSANDRA-9749 that could lose data in some situations. On Wed, Jul 8, 2015 at 7:19 AM Michael Shuler mich...@pbandjelly.org wrote: +1 non-binding On 07/06/2015 01:47 PM, Jake Luciani wrote: I propose the following artifacts for release as 2.2.0-rc2. sha1: ebc50d783505854f04f183297ad3009b9095b07e Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.0-rc2-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1065/org/apache/cassandra/apache-cassandra/2.2.0-rc2/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1065/ The artifacts as well as the debian package are also available here: http://people.apache.org/~jake The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/C1QdHh (CHANGES.txt) [2]: http://goo.gl/NPABEq (NEWS.txt)
Re: Discussion: reviewing larger tickets
I've started leaning towards a hybrid approach: I put everything I want to say, including some code changes, and sometimes complex argumentation into comments the branch. I differentiate these into two categories: 1. Literal comments, to remain for posterity - typically things I agree with, but for which it wasn't immediately clear I would at the outset; and 2. Queries/suggestions for the author, to be removed once they're resolved Then on JIRA, I make sure to raise explicitly for outside input, and for non-code-literate readers for posterity, any more major decisions that need consideration / discussion. Ideally, comments of type 2 would be replaced by summary comments of type 1, also for posterity. You can never have too many comments (so long as they're explanatory, not just restating the code, obviously) I think this probably leads to better JIRA and comments, as we: 1. Avoid the higgledypiggledy JIRA messes that can be very hard to unpick, consciously limiting discussion to high level decisions about approach, or unexpected complexities, etc. The things readers of JIRA care about. 2. Keep decisions about low level minutiae commented directly where they matter, to influence future authors without reference to JIRA On Wed, Jul 8, 2015 at 8:21 PM, Josh McKenzie jmcken...@apache.org wrote: As some of you might have noticed, Tyler and I tossed around a couple of thoughts yesterday regarding the best way to perform larger reviews on JIRA. I've been leaning towards the approach Benedict's been taking lately w/putting comments inline on a branch for the initial author to inspect as that provides immediate locality for a reviewer to write down their thoughts and the same for the initial developer to ingest them. One downside to that approach is that the extra barrier to entry makes it more of a 1-on-1 conversation rather than an open discussion via JIRA comments. Also, if one deletes branches from github we then lose our discussion history on the review process which is a big problem for digging into why certain decisions were made or revised during the process. On the competing side, monster comments like this https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 (which is one of multiple to come) are burdensome to create and map into a JIRA comment and, in my experience, also a burden to map back into the code-base as a developer. Details are lost in translation; I'm comfortable labeling this a sub-optimal method of communication. So what to do? -- Joshua McKenzie
Re: Discussion: reviewing larger tickets
Spark has been using the GitHub PRs successfully; they have an additional mailing list which contains updates from GitHub ( http://mail-archives.apache.org/mod_mbox/spark-reviews/), and they also have their PRs linked to JIRA so that going from the ticket to the PR is easily done. If we are going to start using GitHub PRs to conduct reviews, we should follow similar contribution guidelines to what Spark has ( https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-PullRequest https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark), and have Infra set up the same hooks for our repo. We can also hook up cassci to do the same jobs as the AmplabJenkins performs currently. On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie jmcken...@apache.org wrote: As some of you might have noticed, Tyler and I tossed around a couple of thoughts yesterday regarding the best way to perform larger reviews on JIRA. I've been leaning towards the approach Benedict's been taking lately w/putting comments inline on a branch for the initial author to inspect as that provides immediate locality for a reviewer to write down their thoughts and the same for the initial developer to ingest them. One downside to that approach is that the extra barrier to entry makes it more of a 1-on-1 conversation rather than an open discussion via JIRA comments. Also, if one deletes branches from github we then lose our discussion history on the review process which is a big problem for digging into why certain decisions were made or revised during the process. On the competing side, monster comments like this https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 (which is one of multiple to come) are burdensome to create and map into a JIRA comment and, in my experience, also a burden to map back into the code-base as a developer. Details are lost in translation; I'm comfortable labeling this a sub-optimal method of communication. So what to do? -- Joshua McKenzie
Re: Discussion: reviewing larger tickets
The ability to navigate a patch in an IDE and add comments while exploring is not something the github PR interface can provide; I expect I at least would end up having to use multiple tools to perform a review given the PR approach. On Wed, Jul 8, 2015 at 3:50 PM, Jake Luciani jak...@gmail.com wrote: putting comments inline on a branch for the initial author to inspect I agree and I think we can support this by using github pull requests for review. Pull requests live forever even if the source branch is removed. See https://github.com/apache/cassandra/pull/4 They also allow for comments to be updated over time as new fixes are pushed to the branch. Once review is done we can just close them without committing and just commit the usual way Linking to the PR in JIRA for reference. On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie jmcken...@apache.org wrote: As some of you might have noticed, Tyler and I tossed around a couple of thoughts yesterday regarding the best way to perform larger reviews on JIRA. I've been leaning towards the approach Benedict's been taking lately w/putting comments inline on a branch for the initial author to inspect as that provides immediate locality for a reviewer to write down their thoughts and the same for the initial developer to ingest them. One downside to that approach is that the extra barrier to entry makes it more of a 1-on-1 conversation rather than an open discussion via JIRA comments. Also, if one deletes branches from github we then lose our discussion history on the review process which is a big problem for digging into why certain decisions were made or revised during the process. On the competing side, monster comments like this https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 (which is one of multiple to come) are burdensome to create and map into a JIRA comment and, in my experience, also a burden to map back into the code-base as a developer. Details are lost in translation; I'm comfortable labeling this a sub-optimal method of communication. So what to do? -- Joshua McKenzie -- http://twitter.com/tjake -- Joshua McKenzie DataStax -- The Apache Cassandra Company
Re: Discussion: reviewing larger tickets
(git history navigation is also much more powerful in the IDE, in my experience - can quickly scoot through many prior versions to see what the context of prior authors was) On Wed, Jul 8, 2015 at 9:15 PM, Benedict Elliott Smith belliottsm...@datastax.com wrote: Except that it would lack code navigation. So it would be alt-tabbing, then clicking through the clunky interface to find the file I want, and the location, which can be very cumbersome. On Wed, Jul 8, 2015 at 9:13 PM, Josh McKenzie josh.mcken...@datastax.com wrote: If you navigate in an IDE how do you know if you are commenting on code that has changed or not? I end up in the diff view and alt-tabbing over to the code view to look for details to navigate. In retrospect, working with a github diff would just be tabbing between a browser and IDE vs. an IDE diff and the IDE. On Wed, Jul 8, 2015 at 4:02 PM, Ariel Weisberg ar...@weisberg.ws wrote: Hi, If you navigate in an IDE how do you know if you are commenting on code that has changed or not? My workflow is usually to look at the diff and have it open in an IDE separately, but maybe I am failing hard at tools. Ariel On Jul 8, 2015, at 4:00 PM, Josh McKenzie josh.mcken...@datastax.com wrote: The ability to navigate a patch in an IDE and add comments while exploring is not something the github PR interface can provide; I expect I at least would end up having to use multiple tools to perform a review given the PR approach. On Wed, Jul 8, 2015 at 3:50 PM, Jake Luciani jak...@gmail.com wrote: putting comments inline on a branch for the initial author to inspect I agree and I think we can support this by using github pull requests for review. Pull requests live forever even if the source branch is removed. See https://github.com/apache/cassandra/pull/4 They also allow for comments to be updated over time as new fixes are pushed to the branch. Once review is done we can just close them without committing and just commit the usual way Linking to the PR in JIRA for reference. On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie jmcken...@apache.org wrote: As some of you might have noticed, Tyler and I tossed around a couple of thoughts yesterday regarding the best way to perform larger reviews on JIRA. I've been leaning towards the approach Benedict's been taking lately w/putting comments inline on a branch for the initial author to inspect as that provides immediate locality for a reviewer to write down their thoughts and the same for the initial developer to ingest them. One downside to that approach is that the extra barrier to entry makes it more of a 1-on-1 conversation rather than an open discussion via JIRA comments. Also, if one deletes branches from github we then lose our discussion history on the review process which is a big problem for digging into why certain decisions were made or revised during the process. On the competing side, monster comments like this https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 (which is one of multiple to come) are burdensome to create and map into a JIRA comment and, in my experience, also a burden to map back into the code-base as a developer. Details are lost in translation; I'm comfortable labeling this a sub-optimal method of communication. So what to do? -- Joshua McKenzie -- http://twitter.com/tjake -- Joshua McKenzie DataStax -- The Apache Cassandra Company -- Joshua McKenzie DataStax -- The Apache Cassandra Company
Re: Discussion: reviewing larger tickets
Except that it would lack code navigation. So it would be alt-tabbing, then clicking through the clunky interface to find the file I want, and the location, which can be very cumbersome. On Wed, Jul 8, 2015 at 9:13 PM, Josh McKenzie josh.mcken...@datastax.com wrote: If you navigate in an IDE how do you know if you are commenting on code that has changed or not? I end up in the diff view and alt-tabbing over to the code view to look for details to navigate. In retrospect, working with a github diff would just be tabbing between a browser and IDE vs. an IDE diff and the IDE. On Wed, Jul 8, 2015 at 4:02 PM, Ariel Weisberg ar...@weisberg.ws wrote: Hi, If you navigate in an IDE how do you know if you are commenting on code that has changed or not? My workflow is usually to look at the diff and have it open in an IDE separately, but maybe I am failing hard at tools. Ariel On Jul 8, 2015, at 4:00 PM, Josh McKenzie josh.mcken...@datastax.com wrote: The ability to navigate a patch in an IDE and add comments while exploring is not something the github PR interface can provide; I expect I at least would end up having to use multiple tools to perform a review given the PR approach. On Wed, Jul 8, 2015 at 3:50 PM, Jake Luciani jak...@gmail.com wrote: putting comments inline on a branch for the initial author to inspect I agree and I think we can support this by using github pull requests for review. Pull requests live forever even if the source branch is removed. See https://github.com/apache/cassandra/pull/4 They also allow for comments to be updated over time as new fixes are pushed to the branch. Once review is done we can just close them without committing and just commit the usual way Linking to the PR in JIRA for reference. On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie jmcken...@apache.org wrote: As some of you might have noticed, Tyler and I tossed around a couple of thoughts yesterday regarding the best way to perform larger reviews on JIRA. I've been leaning towards the approach Benedict's been taking lately w/putting comments inline on a branch for the initial author to inspect as that provides immediate locality for a reviewer to write down their thoughts and the same for the initial developer to ingest them. One downside to that approach is that the extra barrier to entry makes it more of a 1-on-1 conversation rather than an open discussion via JIRA comments. Also, if one deletes branches from github we then lose our discussion history on the review process which is a big problem for digging into why certain decisions were made or revised during the process. On the competing side, monster comments like this https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 (which is one of multiple to come) are burdensome to create and map into a JIRA comment and, in my experience, also a burden to map back into the code-base as a developer. Details are lost in translation; I'm comfortable labeling this a sub-optimal method of communication. So what to do? -- Joshua McKenzie -- http://twitter.com/tjake -- Joshua McKenzie DataStax -- The Apache Cassandra Company -- Joshua McKenzie DataStax -- The Apache Cassandra Company
Re: Discussion: reviewing larger tickets
When we set up autojobs for the dev branches, I did some digging around the jenkins / githubPR integration, similar to what spark is doing. I'd be completely on board with working through that setup, if it helps this workflow. Michael On 07/08/2015 03:02 PM, Carl Yeksigian wrote: Spark has been using the GitHub PRs successfully; they have an additional mailing list which contains updates from GitHub ( http://mail-archives.apache.org/mod_mbox/spark-reviews/), and they also have their PRs linked to JIRA so that going from the ticket to the PR is easily done. If we are going to start using GitHub PRs to conduct reviews, we should follow similar contribution guidelines to what Spark has ( https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-PullRequest https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark), and have Infra set up the same hooks for our repo. We can also hook up cassci to do the same jobs as the AmplabJenkins performs currently. On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie jmcken...@apache.org wrote: As some of you might have noticed, Tyler and I tossed around a couple of thoughts yesterday regarding the best way to perform larger reviews on JIRA. I've been leaning towards the approach Benedict's been taking lately w/putting comments inline on a branch for the initial author to inspect as that provides immediate locality for a reviewer to write down their thoughts and the same for the initial developer to ingest them. One downside to that approach is that the extra barrier to entry makes it more of a 1-on-1 conversation rather than an open discussion via JIRA comments. Also, if one deletes branches from github we then lose our discussion history on the review process which is a big problem for digging into why certain decisions were made or revised during the process. On the competing side, monster comments like this https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 (which is one of multiple to come) are burdensome to create and map into a JIRA comment and, in my experience, also a burden to map back into the code-base as a developer. Details are lost in translation; I'm comfortable labeling this a sub-optimal method of communication. So what to do? -- Joshua McKenzie
Discussion: reviewing larger tickets
As some of you might have noticed, Tyler and I tossed around a couple of thoughts yesterday regarding the best way to perform larger reviews on JIRA. I've been leaning towards the approach Benedict's been taking lately w/putting comments inline on a branch for the initial author to inspect as that provides immediate locality for a reviewer to write down their thoughts and the same for the initial developer to ingest them. One downside to that approach is that the extra barrier to entry makes it more of a 1-on-1 conversation rather than an open discussion via JIRA comments. Also, if one deletes branches from github we then lose our discussion history on the review process which is a big problem for digging into why certain decisions were made or revised during the process. On the competing side, monster comments like this https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 (which is one of multiple to come) are burdensome to create and map into a JIRA comment and, in my experience, also a burden to map back into the code-base as a developer. Details are lost in translation; I'm comfortable labeling this a sub-optimal method of communication. So what to do? -- Joshua McKenzie
Re: Discussion: reviewing larger tickets
putting comments inline on a branch for the initial author to inspect I agree and I think we can support this by using github pull requests for review. Pull requests live forever even if the source branch is removed. See https://github.com/apache/cassandra/pull/4 They also allow for comments to be updated over time as new fixes are pushed to the branch. Once review is done we can just close them without committing and just commit the usual way Linking to the PR in JIRA for reference. On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie jmcken...@apache.org wrote: As some of you might have noticed, Tyler and I tossed around a couple of thoughts yesterday regarding the best way to perform larger reviews on JIRA. I've been leaning towards the approach Benedict's been taking lately w/putting comments inline on a branch for the initial author to inspect as that provides immediate locality for a reviewer to write down their thoughts and the same for the initial developer to ingest them. One downside to that approach is that the extra barrier to entry makes it more of a 1-on-1 conversation rather than an open discussion via JIRA comments. Also, if one deletes branches from github we then lose our discussion history on the review process which is a big problem for digging into why certain decisions were made or revised during the process. On the competing side, monster comments like this https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 (which is one of multiple to come) are burdensome to create and map into a JIRA comment and, in my experience, also a burden to map back into the code-base as a developer. Details are lost in translation; I'm comfortable labeling this a sub-optimal method of communication. So what to do? -- Joshua McKenzie -- http://twitter.com/tjake
Re: Discussion: reviewing larger tickets
If you navigate in an IDE how do you know if you are commenting on code that has changed or not? I end up in the diff view and alt-tabbing over to the code view to look for details to navigate. In retrospect, working with a github diff would just be tabbing between a browser and IDE vs. an IDE diff and the IDE. On Wed, Jul 8, 2015 at 4:02 PM, Ariel Weisberg ar...@weisberg.ws wrote: Hi, If you navigate in an IDE how do you know if you are commenting on code that has changed or not? My workflow is usually to look at the diff and have it open in an IDE separately, but maybe I am failing hard at tools. Ariel On Jul 8, 2015, at 4:00 PM, Josh McKenzie josh.mcken...@datastax.com wrote: The ability to navigate a patch in an IDE and add comments while exploring is not something the github PR interface can provide; I expect I at least would end up having to use multiple tools to perform a review given the PR approach. On Wed, Jul 8, 2015 at 3:50 PM, Jake Luciani jak...@gmail.com wrote: putting comments inline on a branch for the initial author to inspect I agree and I think we can support this by using github pull requests for review. Pull requests live forever even if the source branch is removed. See https://github.com/apache/cassandra/pull/4 They also allow for comments to be updated over time as new fixes are pushed to the branch. Once review is done we can just close them without committing and just commit the usual way Linking to the PR in JIRA for reference. On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie jmcken...@apache.org wrote: As some of you might have noticed, Tyler and I tossed around a couple of thoughts yesterday regarding the best way to perform larger reviews on JIRA. I've been leaning towards the approach Benedict's been taking lately w/putting comments inline on a branch for the initial author to inspect as that provides immediate locality for a reviewer to write down their thoughts and the same for the initial developer to ingest them. One downside to that approach is that the extra barrier to entry makes it more of a 1-on-1 conversation rather than an open discussion via JIRA comments. Also, if one deletes branches from github we then lose our discussion history on the review process which is a big problem for digging into why certain decisions were made or revised during the process. On the competing side, monster comments like this https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14617221page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617221 (which is one of multiple to come) are burdensome to create and map into a JIRA comment and, in my experience, also a burden to map back into the code-base as a developer. Details are lost in translation; I'm comfortable labeling this a sub-optimal method of communication. So what to do? -- Joshua McKenzie -- http://twitter.com/tjake -- Joshua McKenzie DataStax -- The Apache Cassandra Company -- Joshua McKenzie DataStax -- The Apache Cassandra Company
