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