On Mon, Aug 18, 2008 at 11:48 PM, Steve Huston <[EMAIL PROTECTED]> wrote:
>> From: Ted Ross [mailto:[EMAIL PROTECTED] >> 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. Yeah, that's always a risk though. Not much we can really do about it either way. > 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? I would hope that this would be in the commit message. > Also, is there someplace relatively easy to check to see if a > particular commit broke something? We don't have the Apache CruiseControl running on Qpid, although there are CC conf's checked in. I keep meaning to engage with infra@ to get us onto there, but haven't found the cycles yet. It sounds like consensus is building around commit-then-review with Jira, so let's go for that. I'll start a formal vote later today. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://cwiki.apache.org/qpid "Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt
