<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 25, 2016 at 6:08 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">> I have a few proposals to reduce this turn around time:<br>
><br>
> 1. We do not clear the Verified tag. This means if you want to re-run<br>
> regressions you have to manually trigger it. If your patch is rebased on<br>
> top<br>
> of another patch, you may have to retrigger failing regressions manually.<br>
> 2. We do give automatic +1 for regressions if the change is *only* in<br>
> `extras/`, to MAINTAINERS file and other no-op changes. Please correct me<br>
> here. I think the changes here do not affect regressions. If I'm wrong and<br>
> they do, I'd love to know which files do affect regressions. I've taken<br>
> the<br>
> MAINTAINERS file as an example, I'm also curious to know what other no-op<br>
> changes can be made.<br>
<br>
</span>I think you're on the right track here, Nigel. :) I'd also add that changes<br>
to one .t file shouldn't require that any others be run (the same is not true<br>
of .rc files though).<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On the more ambitious side, I think we could also optimize around the idea<br>
that some parts of the system aren't even present for some tests. For<br>
example, most of our tests don't even use GFAPI and won't be affected by a<br>
GFAPI-only change. Conversely, GFAPI tests won't be affected by a FUSE-only<br>
change. AFR, EC, and JBR code and tests are mutually exclusive in much the<br>
same way. We have the burn-in test to catch "stragglers" and git to revert<br>
any patch with surprising effects, so IMO (at least on master) we should be<br>
pretty aggressive about pruning out tests that provide little value.<br></blockquote><div><br></div><div> Yes. We introduced #G_TESTDEF_* keys in our .t files with the same idea. Currently, we have two keys </div><div>a. G_TESTDEF_TEST_STATUS_CENTOS6</div><div>b. G_TESTDEF_TEST_STATUS_NETBSD7</div><div><br></div><div>Value for these keys is used by our framework to determine[1] whether to run the test or not. It is fairly easy to add more keys. To take the same example of a GFAPI change,</div><div>G_TESTDEF_TESTS_COMPONENTS="gfapi,dht,afr,"</div><div>G_TESTDEF_NO_IMPACT_COMPONENTS="fuse"<br></div><div><br></div><div>Combination of values from these two keys would decide whether to trigger the test for a change in a component or not.</div><div><br></div><div>If you wish to provide such feature and implement in any different way, ensure that such feature should be usable by the developer on his/her laptop. Hence, it is better if it is developed in the framework than in jenkins/gerrit configuration.</div><div><br></div><div><br></div><div>[1] <a href="http://review.gluster.org/#/c/13393/">http://review.gluster.org/#/c/13393/</a></div><div><br></div></div></div></div>