Hi, I think a rotation model could work. But it might assume fairly broad expertise across the product. I usually read all code reviews but I know much more about the Executor than I do the Windows ODBC driver, so I can offer much better advice on the former.
If committers are active as shepherds while code changes are developed (that is, involved before the code is ready to submit) that would help. Those folks would be subject matter experts in the area(s) being changed. Then multiple committers would be in the loop. I had the impression that the HBase folks have the practice of subject matter experts in various parts of HBase. I saw a web page to this effect but am having trouble finding it now. Dave -----Original Message----- From: Varnau, Steve (Trafodion) Sent: Wednesday, June 03, 2015 11:42 AM To: [email protected] Subject: RE: Proposal: Trafodion Code Development Process in Apache 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 > >
