I have every intention of having automated tests of the pull-requests from the start, but it is not in place yet. And I imagine there may be some rough edges that will improve after we get going.
We don't have core reviewers assigned today, so I'm not sure why we'd need a committer assigned. But the practices can certainly evolve if needed (pull-requests are not reviewed in timely manner). -Steve > -----Original Message----- > From: Sundaresan, Sandhya > Sent: Wednesday, June 03, 2015 11:26 > To: [email protected] > Subject: RE: Proposal: Trafodion Code Development Process in Apache > > Hi, > Automating the tests is very important. We have in the past managed > with the review process not being automated but it has been good to have > that automated as well recently. > Having only the committers be able to write to repository does make some > kind of a bottle neck. I would prefer a weekly or biweekly rotation of > committers rather than have each traf developer pick their committer. I > am afraid some committers will get picked more than others and be over > burndened. If we take turns, on a regular basis it may work better. > I agree with Suresh that we need to get more input. A tech talk and/or > email describing proposed workflow maybe ? > Thanks > Sandhya > > -----Original Message----- > From: Subbiah, Suresh > Sent: Wednesday, June 03, 2015 10:39 AM > To: [email protected] > Subject: RE: Proposal: Trafodion Code Development Process in Apache > > 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 > >
