> -----Original Message----- > From: Ted Ross [mailto:[EMAIL PROTECTED] > > Robert Greig wrote: > > OK, FWIW here's what I would do. No review board, just: > > > > 1) work on issue and commit changes > > 2) mail or IM someone asking if he would mind reviewing it > > 3) assign issue to person doing review and move on until issue is > > either reopened by reviewer or resolved (or whatever state > comes next) > > 4) run jira report regularly of issues in "pending review" > state with > > no activity for 5 days. For those issues go back to step (2) with > > alternative reviewer if necessary. > > > > I think it would be useful to get some of the other > committers' views > > on what would work for them. > > > > RG > +1 to Robert's suggestion > > I think commit-then-review will be more efficient given the > capabilities of our tools.
I agree with this as well, modulo two points. These may be covered already, but I haven't seen evidence of it... 1. If this process gets too far between commit and review, there's increased chance there will be changes add in after the commit that may confuse the reviewer. 2. I haven't seen any sort of log or diary of changes. Something that would, for example, list the files changed and why. Is this normally put in the svn commit comments? Explanatory entries in such a place could help the reviewer get his/her bearings and help understand what the committer was trying to do. Or is this info expected to be in jira? Also, is there someplace relatively easy to check to see if a particular commit broke something? Thanks, -Steve
