If I can chime-in, I could be totally wrong since I'm not heavily involved into development efforts.. but here is what I see so far - but doing some of external QA work:
1) patch has been posted for review - it may stay in review state for quite some time 2) patch has been somewhat reviewed and some fixes were made - but it still stay in review state 3) patch has passed the review and now is commited 4) by the time patch is commited the code base has changed - which could create three additional issues a) the code base has changed and developer needs to re-base his patch b) the QA has been done to some extent - but it may still cause some problems c) external QA of the patch from review board is difficult because code base has changed 5) the patch is commited to master branch - all of sudden people begin to notice it broke feature X, Y or Z Proposed solutions: Create a master-qa branch and push patches into this branch when it reaches step 2 or 3 Cherry-pick the patch from master-qa branch to master branch when its confirm to be acceptable (that is - it wont break other features - and is functional according to specifications) * this approach should minimize issues on master branch and make overall function of master branch more stable Again, I'm not a developer, please chime and correct me if you believe this is not a good approach. Regards ilya it makes it difficult to QA a patch that has not been committed but is in review state. -----Original Message----- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Friday, February 22, 2013 12:18 PM To: cloudstack-dev@incubator.apache.org Subject: Re: [DISCUSS] Code Reviewing process (was Re: Build failed in Jenkins: cloudstack-rat-41 #58) On Fri, Feb 22, 2013 at 04:26:43PM +0530, Rohit Yadav wrote: > Hugo, I just want some better engineering process than the current > one. Yes, we can disagree and have different views on the same thing. > Nonetheless, I just want us to find a better solution, workflow than > the current one, just want to help. I think we all do. ;-) I made this point in another related thread, in that I think that we can look at the behavioural fixes separately from a tooling fix. Let's agree on the "checklist" of things to look at prior to a merge and / or a patch commit. If we agree there, we start holding ourselves to that (and revert or fix when we make a mistake). Tooling can compliment this, but will be a longer lead time to implement and agree on.
