On 03/24/2015 11:17 AM, Lankswert, Patrick wrote: > Jon, > > > Of course, you are right. I should not have said delivery. This is the order > of my checklist. I look for the review first, because it may change code > that can break a unit test. And, any code change as a result of failure in > unit testing or validation sends you back to review. >
The aspect of the workflow I was meaning to highlight is that if unit tests are done as part of the build any feature addition work that breaks any unit test should show up on the developer's machine or at the latest on the build machine as a change is submitted to gerrit. Either of these should have the developer(s) of the feature immediately go back and correct their change. This mini-process loop all should take place before any change is actually sent out for review. Of course, during code reviews it was very common to see notes on areas of the code that might warrant additional test, thus sending things from review back to implementation. And from the higher-level (aka maintainer) view of things, focusing on the review first does make sense. It's the day-to-day process for most developers I wanted to be sure to address. -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at osg.samsung.com
