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 b

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 cod

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 wrote: > > > > If you navigate in an IDE how do you know if y

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 I

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 Ariel Weisberg
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 wrote: > > The abilit

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 wrote: > putting

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 b

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 with,

Re: Discussion: reviewing larger tickets

2015-07-08 Thread Ariel Weisberg
Hi, I really like github’s workflow. If you don’t abuse it you get a history of the entire review process. Right now some people have a workflow that involves force pushing and deleting branches. If you delete branches I think the pull requests are still valid so people can still do it (althou

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 that

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 wrote: > +1 non-binding > > On 07/06/2015 01:47 PM, Jake Luciani wrote: > > I propose the follow

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: https://repository.apac

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: https://reposit