Re: [Gluster-devel] [Gluster-Maintainers] IMPORTANT: New jenkins triggering method

[Raghavendra Talur]

On Tue, Jan 12, 2016 at 7:59 PM, Atin Mukherjee 
wrote:

> -Atin
> Sent from one plus one
> On Jan 12, 2016 7:41 PM, "Niels de Vos"  wrote:
> >
> > On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote:
> > > We have now changed the gerrit-jenkins workflow as follows:
> > >
> > > 1. Developer works on a new feature/bug fix and tests it locally(run
> > > run-tests.sh completely).
> > > 2. Developer sends the patch to gerrit using rfc.sh.
> > >
> > > +++Note that no regression runs have started automatically for this
> patch
> > > at this point.+++
> > >
> > > 3. Developer marks the patch as +1 verified on gerrit as a promise of
> > > having tested the patch completely. For cases where patches don't have
> a +1
> > > verified from the developer, maintainer has the following options
> > > a. just do the code-review and award a +2 code review.
> > > b. pull the patch locally and test completely and award a +1 verified.
> > > Both the above actions would result in triggering of regression runs
> for
> > > the patch.
> >
> > Would it not help if anyone giving +1 code-review starts the regression
> > tests too? When developers ask me to review, I prefer to see reviews
> > done by others first, and any regression failures should have been fixed
> > by the time I look at the change.
> When this idea was originated (long back) I was in favour of having
> regression triggered on a +1, however verified flag set by the developer
> would still trigger the regression. Being a maintainer I would always
> prefer to look at a patch when its verified  flag is +1 which means the
> regression result would also be available.
>


Niels requested in IRC that it is good have a mechanism of getting all
patches that have already passed all regressions before starting review.
Here is what I found
a. You can use the search string
status:open label:Verified+1,user=build AND label:Verified+1,user=nb7build
b. You can bookmark this link and it will take you directly to the page
with list of such patches.

http://review.gluster.org/#/q/status:open+label:Verified%252B1%252Cuser%253Dbuild+AND+label:Verified%252B1%252Cuser%253Dnb7build


>
> >
> > Niels
> >
> > >
> > > 4. Once the regression runs complete, verification verdict is passed
> onto
> > > gerrit by jenkins
> > > and maintainer can proceed with the merge using submit button.
> > >
> > > Thanks,
> > > Raghavendra Talur
> >
> > > ___
> > > maintainers mailing list
> > > maintain...@gluster.org
> > > http://www.gluster.org/mailman/listinfo/maintainers
> >
> >
> > ___
> > 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

Re: [Gluster-devel] [Gluster-Maintainers] IMPORTANT: New jenkins triggering method

[Atin Mukherjee]

-Atin
Sent from one plus one
On Jan 12, 2016 7:41 PM, "Niels de Vos"  wrote:
>
> On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote:
> > We have now changed the gerrit-jenkins workflow as follows:
> >
> > 1. Developer works on a new feature/bug fix and tests it locally(run
> > run-tests.sh completely).
> > 2. Developer sends the patch to gerrit using rfc.sh.
> >
> > +++Note that no regression runs have started automatically for this
patch
> > at this point.+++
> >
> > 3. Developer marks the patch as +1 verified on gerrit as a promise of
> > having tested the patch completely. For cases where patches don't have
a +1
> > verified from the developer, maintainer has the following options
> > a. just do the code-review and award a +2 code review.
> > b. pull the patch locally and test completely and award a +1 verified.
> > Both the above actions would result in triggering of regression runs for
> > the patch.
>
> Would it not help if anyone giving +1 code-review starts the regression
> tests too? When developers ask me to review, I prefer to see reviews
> done by others first, and any regression failures should have been fixed
> by the time I look at the change.
When this idea was originated (long back) I was in favour of having
regression triggered on a +1, however verified flag set by the developer
would still trigger the regression. Being a maintainer I would always
prefer to look at a patch when its verified  flag is +1 which means the
regression result would also be available.
>
> Niels
>
> >
> > 4. Once the regression runs complete, verification verdict is passed
onto
> > gerrit by jenkins
> > and maintainer can proceed with the merge using submit button.
> >
> > Thanks,
> > Raghavendra Talur
>
> > ___
> > maintainers mailing list
> > maintain...@gluster.org
> > http://www.gluster.org/mailman/listinfo/maintainers
>
>
> ___
> 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

Re: [Gluster-devel] [Gluster-Maintainers] IMPORTANT: New jenkins triggering method

[Niels de Vos]

On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote:
> We have now changed the gerrit-jenkins workflow as follows:
> 
> 1. Developer works on a new feature/bug fix and tests it locally(run
> run-tests.sh completely).
> 2. Developer sends the patch to gerrit using rfc.sh.
> 
> +++Note that no regression runs have started automatically for this patch
> at this point.+++
> 
> 3. Developer marks the patch as +1 verified on gerrit as a promise of
> having tested the patch completely. For cases where patches don't have a +1
> verified from the developer, maintainer has the following options
> a. just do the code-review and award a +2 code review.
> b. pull the patch locally and test completely and award a +1 verified.
> Both the above actions would result in triggering of regression runs for
> the patch.

Would it not help if anyone giving +1 code-review starts the regression
tests too? When developers ask me to review, I prefer to see reviews
done by others first, and any regression failures should have been fixed
by the time I look at the change.

Niels

> 
> 4. Once the regression runs complete, verification verdict is passed onto
> gerrit by jenkins
> and maintainer can proceed with the merge using submit button.
> 
> Thanks,
> Raghavendra Talur

> ___
> maintainers mailing list
> maintain...@gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers



signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel