<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 2:43 PM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Thu, Jan 14, 2016 at 11:51:15AM +0530, Raghavendra Talur wrote:<br>
> On Tue, Jan 12, 2016 at 7:59 PM, Atin Mukherjee <<a href="mailto:atin.mukherjee83@gmail.com">atin.mukherjee83@gmail.com</a>><br>
> wrote:<br>
><br>
> > -Atin<br>
> > Sent from one plus one<br>
> > On Jan 12, 2016 7:41 PM, "Niels de Vos" <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br>
> > ><br>
> > > On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote:<br>
> > > > We have now changed the gerrit-jenkins workflow as follows:<br>
> > > ><br>
> > > > 1. Developer works on a new feature/bug fix and tests it locally(run<br>
> > > > run-tests.sh completely).<br>
> > > > 2. Developer sends the patch to gerrit using rfc.sh.<br>
> > > ><br>
> > > > +++Note that no regression runs have started automatically for this<br>
> > patch<br>
> > > > at this point.+++<br>
> > > ><br>
> > > > 3. Developer marks the patch as +1 verified on gerrit as a promise of<br>
> > > > having tested the patch completely. For cases where patches don't have<br>
> > a +1<br>
> > > > verified from the developer, maintainer has the following options<br>
> > > > a. just do the code-review and award a +2 code review.<br>
> > > > b. pull the patch locally and test completely and award a +1 verified.<br>
> > > > Both the above actions would result in triggering of regression runs<br>
> > for<br>
> > > > the patch.<br>
> > ><br>
> > > Would it not help if anyone giving +1 code-review starts the regression<br>
> > > tests too? When developers ask me to review, I prefer to see reviews<br>
> > > done by others first, and any regression failures should have been fixed<br>
> > > by the time I look at the change.<br>
> > When this idea was originated (long back) I was in favour of having<br>
> > regression triggered on a +1, however verified flag set by the developer<br>
> > would still trigger the regression. Being a maintainer I would always<br>
> > prefer to look at a patch when its verified flag is +1 which means the<br>
> > regression result would also be available.<br>
> ><br>
><br>
><br>
> Niels requested in IRC that it is good have a mechanism of getting all<br>
> patches that have already passed all regressions before starting review.<br>
> Here is what I found<br>
> a. You can use the search string<br>
> status:open label:Verified+1,user=build AND label:Verified+1,user=nb7build<br>
> b. You can bookmark this link and it will take you directly to the page<br>
> with list of such patches.<br>
><br>
> <a href="http://review.gluster.org/#/q/status:open+label:Verified%252B1%252Cuser%253Dbuild+AND+label:Verified%252B1%252Cuser%253Dnb7build" rel="noreferrer" target="_blank">http://review.gluster.org/#/q/status:open+label:Verified%252B1%252Cuser%253Dbuild+AND+label:Verified%252B1%252Cuser%253Dnb7build</a><br>
<br>
Hmm, copy/pasting this URL does not work for me, I get an error:<br>
<br>
  Code Review - Error<br>
  line 1:26 no viable alternative at character '%'<br>
  [Continue]<br></blockquote><div><br></div><div>Firefox bug, Works for me in chrome</div><div>Here is the proof</div><div><a href="https://code.google.com/p/gerrit/issues/detail?id=3641">https://code.google.com/p/gerrit/issues/detail?id=3641</a></div><div><a href="https://code.google.com/p/gerrit/issues/detail?id=3582">https://code.google.com/p/gerrit/issues/detail?id=3582</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
Kaushal, could you add the following labels to gerrit, so that we can<br>
update the Jenkins jobs and they can start setting their own labels?<br>
<br>
<a href="http://review.gluster.org/Documentation/config-labels.html#label_custom" rel="noreferrer" target="_blank">http://review.gluster.org/Documentation/config-labels.html#label_custom</a><br>
<br>
- Smoke: misc smoke testing, compile, bug check, posix, ..<br>
- NetBSD: NetBSD-7 regression<br>
- Linux: Linux regression on CentOS-6<br>
<br>
Users/developers should not be able to set these labels, only the<br>
Jenkins accounts are allowed to.<br>
<br>
The standard Verified label can then be used for manual verification by<br>
developers, qa and reviewers.<br>
<br>
Thanks,<br>
Niels<br>
</blockquote></div><br></div></div>