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

[Gaurav Garg]

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 at redhat.com>
To: "Kaushal M" <kshlmster at gmail.com>, "Atin Mukherjee" <amukherj at redhat.com>
Cc: "gluster-infra" <gluster-infra at gluster.org>, "Gluster Devel" <gluster-devel at gluster.org>
Sent: Monday, June 15, 2015 10:08:46 PM
Subject: Re: [Gluster-devel] [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 at gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel