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
+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
+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
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
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
+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
+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
+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
+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.
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
+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,
+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
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
13 matches
Mail list logo
