> >> > - Wes
>> >> >> >
>> >> >> > On Mon, May 9, 2016 at 4:48 PM, Micah Kornfield <
>> >> emkornfi...@gmail.com>
>> >> >> > wrote:
>> >> >> > > Does gerrit work well with TravisCI, or will we need to
>> >> develop
t; > >
> >> >> > > On Wed, May 4, 2016 at 10:08 PM, Daniel Robinson
> >> >> > > wrote:
> >> >> > >> Admittedly, coming from the complete opposite end of the
> >> commit-size
> >> >> > spectrum, the JIR
> > wrote:
>> >> > >> Admittedly, coming from the complete opposite end of the
>> commit-size
>> >> > spectrum, the JIRA issue + GitHub pull request workflow already feels
>> a
>> >> > little frictional for simple bugfixes and additions, so I was wary of
>> >>
frictional for simple bugfixes and additions, so I was wary of
> >> > Gerrit. But it actually looks pretty well-suited to small commits.
> >> > >> One advantage I'd see to different platforms, though, would be the
> >> > potential for JIRA integration. GitHub seems to have a more built-in
> >> > solu
> solution for this, if it's something you could foresee setting up. But
>> > there seem to be ways to do it with Gerrit too.
>> > >> Clearly having an option to use GitHub pull requests lowers the
>> > barriers to entry for contributors, but I understand
> > solution for this, if it's something you could foresee setting up. But
> > there seem to be ways to do it with Gerrit too.
> > >> Clearly having an option to use GitHub pull requests lowers the
> > barriers to entry for contributors, but
gt; Clearly having an option to use GitHub pull requests lowers the
> barriers to entry for contributors, but I understand easy pull requests are
> a double-edged sword for maintainers!
> >>
> >>
> >>
> >> _
> >&g
y for contributors, but I understand easy pull requests are a
>> double-edged sword for maintainers!
>>
>>
>>
>> _________
>> From: Wes McKinney
>> Sent: Thursday, May 5, 2016 12:46 AM
>> Subject: Re: Code review tools for Arrow patches
>> To:
>&
requests are a
> double-edged sword for maintainers!
>
>
>
> _
> From: Wes McKinney
> Sent: Thursday, May 5, 2016 12:46 AM
> Subject: Re: Code review tools for Arrow patches
> To:
>
>
> I'm also on board with this if it d
sts lowers the barriers to
entry for contributors, but I understand easy pull requests are a double-edged
sword for maintainers!
_
From: Wes McKinney
Sent: Thursday, May 5, 2016 12:46 AM
Subject: Re: Code review tools for Arrow patches
To:
I'm also on
On Tue, May 3, 2016 at 6:59 AM, Jacques Nadeau wrote:
> I dont know about the other pmc members and committers but I prefer just
> making Gerrit the only way to submit patches rather than one of many. It
> seems to work well for Asterix and Kudu.
>
I'd say go for it. Can always undo if it prove
I'm also on board with this if it doesn't deter new contributors (it's
a bit of additional process over GitHub but overall not too hard to
learn).
On Tue, May 3, 2016 at 9:59 AM, Jacques Nadeau wrote:
> I dont know about the other pmc members and committers but I prefer just
> making Gerrit the o
I dont know about the other pmc members and committers but I prefer just
making Gerrit the only way to submit patches rather than one of many. It
seems to work well for Asterix and Kudu.
On Apr 25, 2016 12:16 PM, "Todd Lipcon" wrote:
> On Mon, Apr 25, 2016 at 12:09 PM, Wes McKinney wrote:
>
> >
On Mon, Apr 25, 2016 at 12:09 PM, Wes McKinney wrote:
> hi Todd,
>
> This is helpful to know, thank you. As you say, by "optional" what I
> meant was that code could be optionally reviewed in Gerrit, but then
> commits would have to be cherry-picked by the committer from the
> Gerrit git remote.
hi Todd,
This is helpful to know, thank you. As you say, by "optional" what I
meant was that code could be optionally reviewed in Gerrit, but then
commits would have to be cherry-picked by the committer from the
Gerrit git remote. We would continue to accept patches via GitHub pull
requests (but f
Using gerrit as an "optional" tool is a bit difficult, because it doesn't
know how to handle commits to a repository that it doesn't own.
The way we get around the "commit via gerrit" issue in the Kudu podling is
to follow the example of AsterixDB. Commits are made using gerrit, but that
doesn't a
IIRC Apex wanted to commit via Gerrit. That was a non-starter. Commits have to
be made by a committer.
Julian
> On Apr 24, 2016, at 3:07 PM, Wes McKinney wrote:
>
> Sending all Gerrit review activity to the mailing list seems adequate to me.
> I don't see how this is especially different from
Sending all Gerrit review activity to the mailing list seems adequate to me.
I don't see how this is especially different from reviewing code on a
website owned by GitHub. I remain hopeful that ASF Infra will set up an
ASF-managed Gerrit.
On Sunday, April 24, 2016, Ted Dunning wrote:
> Just for
Just for the record, Apex had some issues getting Gerrit reviews reflected
in a coherent fashion into the Apache record. I presume that you guys will
have that handled or will check with the Apex devs to learn their
resolution.
On Sun, Apr 24, 2016 at 5:30 PM, Wes McKinney wrote:
> Todd, woul
Todd, would you (or someone who is familiar with Gerrit
administration) mind setting up gerrit.cloudera.org projects that we
can use for apache/arrow and apache/parquet-cpp? We're having more
larger patches to both projects and I'm having a difficult time
staying organized in my reviews on GitHub (
hey Jason,
I have not used Reviewboard, but the problems you are describing are
(AFAICT) not common complaint among Gerrit users. It would be helpful
to hear more from experienced Gerrit users.
Note that my initial request was not "let's choose a tool that is not
GitHub PRs" for code reviews but
It looks like I am going to be a minority opinion here, but I think there
is at least a case to make that pull requests area little easier for
newcomers.
I also have opinions about rebasing branches that are shared publicly or
currently under review. While it isn't often a problem, rebasing often
i
+1 for Gerrit from me too -- we're using it on Kudu and everyone on the
team likes it.
Happy to help admin the server on the gerrit.cloudera.org box which hosts
Kudu and Impala
-Todd
On Fri, Apr 15, 2016 at 8:48 AM, Wes McKinney wrote:
> In my experience, GitHub pull requests are only appropri
In my experience, GitHub pull requests are only appropriate for patches
that do not evolve significantly from the first iteration. Changes to
patches frequently cause outstanding points of discussion to be obscured
(the dreaded "comment on an outdated diff").
Rebasing also frequently puts GitHub t
I'm not seeing either is good over the other, but did notice that many good
discussions in PR reviewing not seen here, though concrete comments for some
codes in place are very convenient comparing with JIRA based reviewing. No one
just looks to be perfect.
Regards,
Kai
-Original Message--
My preference in order is:
1. Gerrit
2. Review board
3. GH PRs
The lack of transactionality and good history makes GH PRs frequently
inadequate. (We used them as the default on Drill for the last year.) The
per comment email model is also ridiculous.
On Thu, Apr 14, 2016 at 3:27 PM, Henry Saputr
How about using Github Pull Requests as mechanism to do review?
So, all patches need to be done via Github mirror PRs, similar to Flink and
Spark and other new projects have been doing.
At AsterixDB we did Gerrit and has to do some tooling to make sure it
comply with ASF way.
- Henry
On Thu, Ap
I agree, we need a code review tools as well for Mnemonic. We are going to
submit large patches. I include mnemonic dev list here for discussion.
Thanks
> On Apr 14, 2016, at 10:39 AM, Wes McKinney wrote:
>
> hello all,
>
> We're reaching a junction where larger patches to the Arrow codebase
28 matches
Mail list logo
