> I have a few proposals to reduce this turn around time: > > 1. We do not clear the Verified tag. This means if you want to re-run > regressions you have to manually trigger it. If your patch is rebased on > top > of another patch, you may have to retrigger failing regressions manually. > 2. We do give automatic +1 for regressions if the change is *only* in > `extras/`, to MAINTAINERS file and other no-op changes. Please correct me > here. I think the changes here do not affect regressions. If I'm wrong and > they do, I'd love to know which files do affect regressions. I've taken > the > MAINTAINERS file as an example, I'm also curious to know what other no-op > changes can be made. I think you're on the right track here, Nigel. :) I'd also add that changes to one .t file shouldn't require that any others be run (the same is not true of .rc files though). On the more ambitious side, I think we could also optimize around the idea that some parts of the system aren't even present for some tests. For example, most of our tests don't even use GFAPI and won't be affected by a GFAPI-only change. Conversely, GFAPI tests won't be affected by a FUSE-only change. AFR, EC, and JBR code and tests are mutually exclusive in much the same way. We have the burn-in test to catch "stragglers" and git to revert any patch with surprising effects, so IMO (at least on master) we should be pretty aggressive about pruning out tests that provide little value. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
