Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-25 Thread Yi Pan
Thanks for all the +1s! I have created https://issues.apache.org/jira/browse/SAMZA-880 to track it. Thanks! -Yi On Wed, Feb 24, 2016 at 5:31 PM, Boris Shkolnik wrote: > +1 for pull requests. > > On Thu, Feb 18, 2016 at 3:53 PM, Yi Pan wrote: > > > Hi, all, > > > > I want to start the discussi

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-24 Thread Boris Shkolnik
+1 for pull requests. On Thu, Feb 18, 2016 at 3:53 PM, Yi Pan wrote: > Hi, all, > > I want to start the discussion on our code review/commit process. > > I felt that our code review and check-in process is a little bit > cumbersome: > - developers need to create RBs and attach diff to JIRA > - c

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-20 Thread Chinmay Soman
+1 for pull requests. On Fri, Feb 19, 2016 at 3:12 PM, Yi Pan wrote: > Hi, Julian, > > Thanks for the input. It is a good point that directly merge on github may > result in non-linear history in the master branch. I just checked the > kafka-merge-pr.py script Kafka uses to merge the PRs to mas

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-19 Thread Yi Pan
Hi, Julian, Thanks for the input. It is a good point that directly merge on github may result in non-linear history in the master branch. I just checked the kafka-merge-pr.py script Kafka uses to merge the PRs to master and the basic workflow it implements is the same as what we manually enforce a

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-19 Thread Julian Hyde
PRs have worked well for us in Calcite. We still accept patches, if contributors are adamant, but it’s unusual. We don’t use RB. We (or I) haven’t managed to fully automate submission. I pull down to my sandbox, rebase, and merge --ff-only, because in Calcite (as I think in Samza) our policy i

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-19 Thread Jagadish Venkatraman
+1 attaching patches to jira is heavy weight. On Friday, February 19, 2016, Yan Fang wrote: > +1. > > Though I am familiar with the current way, still think the pull requests > are simpler. > > Cheers, > > Fang, Yan > yanfang...@gmail.com > > On Fri, Feb 19, 2016 at 11:10 AM, Milinda Pathirage

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-19 Thread Yan Fang
+1. Though I am familiar with the current way, still think the pull requests are simpler. Cheers, Fang, Yan yanfang...@gmail.com On Fri, Feb 19, 2016 at 11:10 AM, Milinda Pathirage wrote: > +1. Calcite uses pull requests for contributions from non-committers and > according to my experience w

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-18 Thread Milinda Pathirage
+1. Calcite uses pull requests for contributions from non-committers and according to my experience with Calcite, pull requests are easier than the current approach we follow in Samza. Milinda On Thu, Feb 18, 2016 at 9:09 PM, Roger Hoover wrote: > +1 - Thanks for bringing this up, Yi. I've don

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-18 Thread Roger Hoover
+1 - Thanks for bringing this up, Yi. I've done it both ways and feel pull requests are much easier. Sent from my iPhone > On Feb 18, 2016, at 4:25 PM, Navina Ramesh > wrote: > > +1 > > Haven't tried any contribution with pull requests. But sounds simpler than > attaching the patch to JIRA.

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-18 Thread Edi Bice
Yay! > On Feb 18, 2016, at 7:25 PM, Navina Ramesh > wrote: > > +1 > > Haven't tried any contribution with pull requests. But sounds simpler than > attaching the patch to JIRA. > > Navina > >> On Thu, Feb 18, 2016 at 4:01 PM, Jacob Maes wrote: >> >> +1 >> >> As a relatively new contributor

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-18 Thread Navina Ramesh
+1 Haven't tried any contribution with pull requests. But sounds simpler than attaching the patch to JIRA. Navina On Thu, Feb 18, 2016 at 4:01 PM, Jacob Maes wrote: > +1 > > As a relatively new contributor to Samza, I've certainly felt the current > process was overly-complicated. > > On Thu,

Re: [DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-18 Thread Jacob Maes
+1 As a relatively new contributor to Samza, I've certainly felt the current process was overly-complicated. On Thu, Feb 18, 2016 at 3:53 PM, Yi Pan wrote: > Hi, all, > > I want to start the discussion on our code review/commit process. > > I felt that our code review and check-in process is a

[DISCUSS] Moving to github/pull-request for code review and check-in

2016-02-18 Thread Yi Pan
Hi, all, I want to start the discussion on our code review/commit process. I felt that our code review and check-in process is a little bit cumbersome: - developers need to create RBs and attach diff to JIRA - committers need to review RBs, dowload diff and apply, then push. It would be much lig