On Jun 15, 2015 10:08 PM, "Saravanakumar Arumugam" <sarum...@redhat.com> wrote: > > Hi, > > > - Developer pushes change to Gerrit. > > - Zuul is notified by Gerrit of new change > > - Zuul runs pre-review checks on Jenkins. This will be the current smoke tests. > > - Zuul reports back status of the checks to Gerrit. > > - If checks fail, developer will need to resend the change after > > the required fixes. The process starts once more. > > - If the checks pass, the change is now ready for review > > - The change is now reviewed by other developers and maintainers. > > Non-maintainers will be able to give only a +1 review. > > - On a negative review, the developer will need to rework the change > > and resend it. The process starts once more. > > - The maintainer give a +2 review once he/she is satisfied. The > > maintainers work is done here. > > - Zuul is notified of the +2 review > > - Zuul runs the regression runs and reports back the status. > > - If the regression runs fail, the process starts over again. > > - If the runs pass, the change is ready for acceptance. > > - Zuul will pick the change into the repository. > > - If the pick fails, Zuul will report back the failure, and the > > process starts once again. > > +2 for the idea. > > Can we have a small change in this flow ? > ====================================== > What is proposed now: ( as per my understanding) > > Reviewer1 gives +1 > Reviewer2 gives +1 > > Maintainer gives +2 (for merge) > > Now, regression triggered => Regression failed. > > So, code is again changed by Developer. > > Now, review needs to be done by Reviewer1/Reviewer2/Maintainer. > ====================================== > A small change in the proposal: > > Reviewer1 gives +1 > > A single +1 is enough to get Regression Triggered. > Lets say immediately Regression triggered and Failed. > > So, developer Re-submit his/her changes. > > Goes through Reviewer1, Reviewer2, Maintainer. I still feel triggering regression on +2 is better as this patch is then a serious candidate for merge and having that criteria will have the regression queue pretty light weight. Even if a patch goes for iterations I don't see any reason of delay if regression is not triggered on +1.
Cheers, Atin > > ====================================== > > How this helps? > It does not goes through the process from the beginning(especially when there is a Regression failure). > << - If the regression runs fail, the process starts over again. > > Thanks, > Saravanakumar > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel