<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">&lt;<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>&gt;</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>
&gt; On Tue, Jan 12, 2016 at 7:59 PM, Atin Mukherjee &lt;<a href="mailto:atin.mukherjee83@gmail.com">atin.mukherjee83@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt; &gt; -Atin<br>
&gt; &gt; Sent from one plus one<br>
&gt; &gt; On Jan 12, 2016 7:41 PM, &quot;Niels de Vos&quot; &lt;<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>&gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote:<br>
&gt; &gt; &gt; &gt; We have now changed the gerrit-jenkins workflow as follows:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 1. Developer works on a new feature/bug fix and tests it locally(run<br>
&gt; &gt; &gt; &gt; run-tests.sh completely).<br>
&gt; &gt; &gt; &gt; 2. Developer sends the patch to gerrit using rfc.sh.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; +++Note that no regression runs have started automatically for this<br>
&gt; &gt; patch<br>
&gt; &gt; &gt; &gt; at this point.+++<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 3. Developer marks the patch as +1 verified on gerrit as a promise of<br>
&gt; &gt; &gt; &gt; having tested the patch completely. For cases where patches don&#39;t have<br>
&gt; &gt; a +1<br>
&gt; &gt; &gt; &gt; verified from the developer, maintainer has the following options<br>
&gt; &gt; &gt; &gt; a. just do the code-review and award a +2 code review.<br>
&gt; &gt; &gt; &gt; b. pull the patch locally and test completely and award a +1 verified.<br>
&gt; &gt; &gt; &gt; Both the above actions would result in triggering of regression runs<br>
&gt; &gt; for<br>
&gt; &gt; &gt; &gt; the patch.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Would it not help if anyone giving +1 code-review starts the regression<br>
&gt; &gt; &gt; tests too? When developers ask me to review, I prefer to see reviews<br>
&gt; &gt; &gt; done by others first, and any regression failures should have been fixed<br>
&gt; &gt; &gt; by the time I look at the change.<br>
&gt; &gt; When this idea was originated (long back) I was in favour of having<br>
&gt; &gt; regression triggered on a +1, however verified flag set by the developer<br>
&gt; &gt; would still trigger the regression. Being a maintainer I would always<br>
&gt; &gt; prefer to look at a patch when its verified  flag is +1 which means the<br>
&gt; &gt; regression result would also be available.<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt; Niels requested in IRC that it is good have a mechanism of getting all<br>
&gt; patches that have already passed all regressions before starting review.<br>
&gt; Here is what I found<br>
&gt; a. You can use the search string<br>
&gt; status:open label:Verified+1,user=build AND label:Verified+1,user=nb7build<br>
&gt; b. You can bookmark this link and it will take you directly to the page<br>
&gt; with list of such patches.<br>
&gt;<br>
&gt; <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 &#39;%&#39;<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>