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. 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 <ste...@hortonworks.com> wrote: > >> On 30 Oct 2015, at 17:15, Colin P. McCabe <cmcc...@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). > >
