Hi Steve, Thank you for this nice proposal. I too would prefer to use github pull requests rather than ReviewBoard or patch files in Jira.
In the new approach, to replace workflow requirements provided by Gerrit this is one possibility 1) Each contributor picks out one or more committers to deliver/merge their change 2) The committer runs required regressions after merge (preferably using some automated setup) 3) Ensures code is reviewed by a minimum number of folks 4) delivers the merged change. In effect the committer does what gerrit does for us today. If there is a regression failure or review issue, contributor provides a new patchset to commiter. Is this procedure too manual? Should we have this discussion on one of the current traf dlists where more people can weigh in? This is always a topic with multiple points of view. We could copy this dlist to ensure that apache has the discussion archived? Thanks Suresh -----Original Message----- From: Varnau, Steve (Trafodion) Sent: Wednesday, June 03, 2015 11:35 AM To: [email protected] Subject: Proposal: Trafodion Code Development Process in Apache Trafodion Dev, I'm working on the process for how we'll manage code changes once our code migrates to Apache git server. Our current process won't work, so changes will be needed. I have a proposal for how it will work, but am looking for feedback. We currently submit code changes to Gerrit site (review.trafodion.org) for code review and automated testing. It enforces certain workflow criteria of reviews and tests and merges the code automatically. While Gerrit is highly configurable, it does require that it run against the canonical repo and then mirrors it elsewhere. That basic assumption is incompatible with the canonical repo being on the Apache server and committers having the only write access. Also, one of the most confusing things about our current usage of git is the way Gerrit requires changes to be packaged in single commit and with separate change-IDs in the comments. Changing our process will have the side benefit of avoiding those issues. Other Apache projects tend to submit code contributions in one three ways: Jira (attaching a patch file), ReviewBoard, GitHub pull-request Some projects use two of the three methods. In general, each project has specific instructions on which method you should use. While github is not running on the Apache infrastructure, Apache infra team provides integrations, so that github activity is mirrored over to Apache Jira and/or mail lists. That satisfies the Apache requirements to archive info related to community work and code provenance. None of the three available mechanisms provides workflow requirements like Gerrit. Rather, they rely on committers' judgment to ensure project criteria are satisfied and merge the code in. What we need, however, is the basic code review and test automation capabilities. In my estimation, GitHub provides the best support for code review and test automation. I'm currently working on changing our Jenkins testing automation to plug into GitHub, rather than Gerrit/Zuul. Of course, it may take a little while to get that working smoothly, but it is certainly do-able. >From the development point of view, everyone would need a github account, >rather than gerrit account. The workflow would be to do work on a branch, push >the branch to their fork on github, then make a pull-request on github. I'll >provide some detailed instructions on the wiki. In order to facilitate working >with github, I recommend folks use the git wrapper tool call "hub": >https://hub.github.com/ Details to come, but I wanted to start the discussion whether this is the right direction. -Steve
