<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 7:19 PM, Nigel Babu <span dir="ltr">&lt;<a href="mailto:nigelb@redhat.com" target="_blank">nigelb@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jun 21, 2017 at 06:05:32PM +0530, Atin Mukherjee wrote:<br>
&gt; On Tue, Jun 20, 2017 at 9:17 AM, Nigel Babu &lt;<a href="mailto:nigelb@redhat.com">nigelb@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Hello folks,<br>
&gt; &gt;<br>
&gt; &gt; Amar has proposed[1] these changes in the past and I&#39;d like to announce us<br>
&gt; &gt; going<br>
&gt; &gt; live with them as we&#39;ve not received any strong feedback against it.<br>
&gt; &gt;<br>
&gt; &gt; ## Centos Regression<br>
&gt; &gt; * On master, we only run tests/basic as pre-merge testing.<br>
&gt; &gt;<br>
&gt;<br>
&gt; I should have read this and Amar&#39;s email thread more carefully but<br>
&gt; unfortunately I missed to read the above point in both the cases, so<br>
&gt; apologies. I think running only tests/basic on master is not *sufficient*<br>
&gt; given our goal is to have more test coverages coming from each patch and I<br>
&gt; expect most of the patches if not all will have tests added and if we don&#39;t<br>
&gt; run the full regression suite this eventually means we don&#39;t test the patch<br>
&gt; on master. Also I&#39;m not sure how reactive we are against the regression<br>
&gt; test burn failure reports, so if things go bad and if we don&#39;t react to it<br>
&gt; immediately it&#39;d be difficult to get the master branch back to stable<br>
&gt; state. I&#39;d suggest (and request) that we should run the full regression<br>
&gt; test suite on Centos.<br>
<br>
</span>These are valid concerns. I don&#39;t have an easy solution to any of them. So I&#39;ve<br>
reverted the Centos regression changes entirely.<br></blockquote><div><br></div><div>Atin, thanks for highlighting it. Yes, I didn&#39;t foresee these issues when I proposed the changes.<br><br></div><div>With &#39;experimental&#39; branch, which doesn&#39;t run regressions, the issue I was trying to make (Multiple smaller patchesets to complete a feature) gets solved. Hence keeping full regressions on master makes sense.<br><br></div><div>Thanks Nigel, for reverting back to normalcy quickly!<br><br></div><div>-Amar<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
&gt; &gt; * On release branches, we will run the entire suite of tests.<br>
&gt; &gt; * Our regular regression-test-burn-in and regression-test-with-multiplex<br>
&gt; &gt; will<br>
&gt; &gt;   continue to run the full suite of tests as they currently do.<br>
&gt; &gt;<br>
&gt; &gt; ## NetBSD Regression<br>
&gt; &gt; * We will not run a netbsd7-regression as required pre-merge test anymore.<br>
&gt; &gt;   However, you should be able to trigger it with &quot;recheck netbsd&quot;.<br>
&gt; &gt; * A green NetBSD will no longer be required for merging patches, however<br>
&gt; &gt; if you<br>
&gt; &gt;   have a -1 vote, it will remain a blocker. This is so that reviewers can<br>
&gt; &gt;   request a full NetBSD run, especially on release branches.<br>
&gt; &gt; * We will do a periodic NetBSD regression run on all currently maintained<br>
&gt; &gt;   branches (3.8, 3.10, and 3.11 at the moment) and master.<br>
&gt; &gt;<br>
&gt; &gt; ## Additional Changes<br>
&gt; &gt; * As full regression runs per patch is run on release branches only (other<br>
&gt; &gt; than<br>
&gt; &gt;   the nightly on master), any failures need proper attention and possible<br>
&gt; &gt; RCA.<br>
&gt; &gt;   A re-trigger in the hopes of getting a green is no longer acceptable for<br>
&gt; &gt;   release branches.<br>
&gt; &gt; * fstat will soon track the regression-test-burn-in and<br>
&gt; &gt;   regression-test-with-<wbr>multiplex.<br>
&gt; &gt; * As soon as we have the new jobs up, we&#39;ll add them to fstat so we can<br>
&gt; &gt; track<br>
&gt; &gt;   failure patterns.<br>
&gt; &gt;<br>
&gt; &gt; The CentOS changes are already in production. The NetBSD changes will land<br>
&gt; &gt; in<br>
&gt; &gt; production today.<br>
&gt; &gt;<br>
&gt; &gt; [1]: <a href="http://lists.gluster.org/pipermail/gluster-devel/2017-May/052868.html" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>pipermail/gluster-devel/2017-<wbr>May/052868.html</a><br>
<br>
--<br>
nigelb<br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</div></div>