On Wed, Jun 3, 2015 at 11:25 AM, Sundaresan, Sandhya < [email protected]> wrote:
> 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. > Yeah, lets make this work. Hadoop has been doing some nice work of late generalizing their CI scripts. T8 might be able to make use of these. Some projects trigger CI by attaching patch to JIRA and clicking 'submit' AND they have CI run tests post commit. > 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. > You could anoint more committers! St.Ack > 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 > > > >
