Hi, some more cleaner way: >>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. The idea is good but I think it will make more dependent on maintainer to run a regression test. Maintainer will give +2 only after reviewing of full patch. If maintainer will busy in some other work which is higher priority then reviewing this patch (and giving +2 if patch are good) might be delay and it might delay regression test to run. It is good if any Reviewer give +1 (after reviewing patch) for triggering regression test. other idea http://www.gluster.org/pipermail/gluster-devel/2014-May/040822.html we can have docker based regression test run to improve our regression test time. Thanx, Regards, Gaurav Garg >>So, code is again changed by Developer. ----- Original Message ----- From: "Saravanakumar Arumugam" <sarumuga@xxxxxxxxxx> To: "Kaushal M" <kshlmster@xxxxxxxxx>, "Atin Mukherjee" <amukherj@xxxxxxxxxx> Cc: "gluster-infra" <gluster-infra@xxxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx> Sent: Monday, June 15, 2015 10:08:46 PM Subject: Re: [Gluster-infra] Reduce regression runs wait time - New gerrit/review work flow 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. ====================================== 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@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
