Re: Github integration for Hadoop

[Steve Loughran <st...@hortonworks.com>]

> On 31 Oct 2015, at 17:58, Colin P. McCabe <cm...@apache.org> wrote:
> 
> Thanks for your responses here.  It sounds like the proposal here is
> for doing code reviews on GH, but still doing commits in our existing
> way.  Since it wasn't spelled out in the initial proposal, I
> interpreted it as doing both reviews and commits on GH, like Spark
> does-- which I think is problematic for all the reasons we've
> discussed here (the fact that GH introduces merge commits, the
> possibility of bypassing jira, duplicate pull requests with no search
> features to dedup them, etc. etc.)  Nobody has really come up with a
> solution for the problems caused by __committing__ through GH that
> scales to our size of community.
> 
> If there is a general consensus that __code reviews__ through GH would
> be helpful, I will change my -1 to a +0 for that.  But let's make sure
> that we are not __commiting__ through GH.  I view this as kind of an
> experiment to see how much easier things are this way, so I will try
> to keep an open mind.

+1 for that.

in fact, we may want to start a wiki page on reviewing through github, to get these policies written down

> 
> In parallel with this experiment, I also think we should set up a
> gerrit instance that supports code reviews and precommit testing.  As
> I said, Cloudera uses gerrit internally and we are very happy with it.
> It is nicer than GH because we can set up our own precommit hooks.
> For example, we can reject gerrit change requests that don't have a
> jira number associated with them.  Gerrit change requests can be
> created entirely from the command line as well.  Gerrit is open
> source, and doesn't create merge commits for everything if you commit
> through it.
> 
> I think we can support multiple solutions in parallel and let people
> gravitate to the most convenient one, as long as we keep our project
> history accessible on JIRA and the mailing lists.  Also, as Andrew
> commented, let's make sure we are not setting up duplicate bug
> trackers or mailing lists on GH-- one of each of those is enough :)
> 
> Colin
> 
> On Sat, Oct 31, 2015 at 4:40 AM, Steve Loughran <st...@hortonworks.com> wrote:
>> 
>>> On 30 Oct 2015, at 17:15, Colin P. McCabe <cm...@apache.org> wrote:
>>> 
>>> I think the Spark guys eventually built some kind of UI on top of
>>> github to help them search through pull requests.  We would probably
>>> also need something like this.
>> 
>> https://spark-prs.appspot.com/users
>> 
>> 
>> They do have to impose naming scheme on those patches to help identify the area. You can just watch a JIRA and wait for a pull-req to arrive.
>> 
>>> 
>>> Spark uses github partially because it started as a github project, so
>>> everyone was familiar with that.  I haven't seen an answer to Andrew's
>>> question about what the value add is here for Hadoop to move to a new
>>> system.  I have seen a few comments about a better review UI and
>>> one-click patch submission, is that the main goal?
>> 
>> I do think it is good for a very fast cycle time on reviews, though that depends, of course on reviewers willing to put in the time (credit to your colleagues here, Colin).
>> 
>> 
> 

Re: Github integration for Hadoop

[Sean Busbey <bu...@cloudera.com>]

On Sun, Nov 1, 2015 at 12:52 PM, Allen Wittenauer <aw...@altiscale.com> wrote:
>
>> On Nov 1, 2015, at 6:05 AM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>>
>> Thank you for starting this discussion. It's good for us to rethink
>> our workflow to grow community.
>> However, at the moment, my concern is that we can put more pressure on
>> Yetus community if we move the main workflows into github.
>>
>> Allen and Sean, what do you think? Is it good timing for Yetus community?
>
>
>         There’s nothing for Yetus to do here; support for github PRs has been there since August. I regularly use it to pull down my own PRs against my own hadoop branch to test with.
>
>         The only work is for someone to modify the Jenkins job that runs test-patch to either support both JIRA and GH or to create another job.  That’s on the Hadoop community to do.

Just one additional Yetus point here: no new jenkins job is needed if
folks leave a comment with a link to their PR and set the jira status
to "patch available".

-- 
Sean

Re: Github integration for Hadoop

[Allen Wittenauer <aw...@altiscale.com>]

> On Nov 1, 2015, at 6:05 AM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
> 
> Thank you for starting this discussion. It's good for us to rethink
> our workflow to grow community.
> However, at the moment, my concern is that we can put more pressure on
> Yetus community if we move the main workflows into github.
> 
> Allen and Sean, what do you think? Is it good timing for Yetus community?


	There’s nothing for Yetus to do here; support for github PRs has been there since August. I regularly use it to pull down my own PRs against my own hadoop branch to test with.

	The only work is for someone to modify the Jenkins job that runs test-patch to either support both JIRA and GH or to create another job.  That’s on the Hadoop community to do.

Re: Github integration for Hadoop

[Tsuyoshi Ozawa <oz...@apache.org>]

Thank you for starting this discussion. It's good for us to rethink
our workflow to grow community.
However, at the moment, my concern is that we can put more pressure on
Yetus community if we move the main workflows into github.

Allen and Sean, what do you think? Is it good timing for Yetus community?

Best,
- Tsuyoshi