[Gluster-devel] [Gluster-infra] Reduce regression runs wait time - New gerrit/review work flow

[Atin Mukherjee]

On Jun 15, 2015 10:08 PM, "Saravanakumar Arumugam" <sarumuga at 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 at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150615/54d89d87/attachment.html>