Re: [VOTE] Release Apache Cassandra 2.2.0-rc2

2015-07-08 Thread Michael Shuler
+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:

Re: [VOTE] Release Apache Cassandra 2.1.8

2015-07-08 Thread Michael Shuler
+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:

Re: [VOTE] Release Apache Cassandra 2.2.0-rc2

2015-07-08 Thread Blake Eggleston
-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

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Benedict Elliott Smith
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

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Carl Yeksigian
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

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Josh McKenzie
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

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Benedict Elliott Smith
(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

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Benedict Elliott Smith
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

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Michael Shuler
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

Discussion: reviewing larger tickets

2015-07-08 Thread Josh McKenzie
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

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Jake Luciani
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

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Josh McKenzie
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