[Gluster-devel] [Feature request]: Regression to take more patches in single instance

Varun Shastry vshastry at redhat.com
Fri Aug 2 08:32:34 UTC 2013


On Wednesday 31 July 2013 05:17 PM, Kaleb S. KEITHLEY wrote:
> On 07/31/2013 07:35 AM, Amar Tumballi wrote:
>> Hi,
>>
>> I was trying to fire some regression builds on very minor patches today,
>> and noticed (always known, but faced pain of 'waiting' today) that we
>> can fire regression build on only one patch (or a patchset if its
>> submitted with dependency added while submitting). And each regression
>> run takes approx 30mins.
>>
>> With this model, we can at max take only ~45 patches in a day, which
>> won't scale up if we want to grow with more people participating in code
>> contribution. Would be great to have an option to submit regression run
>> with multiple patch numbers, (technically they should be applicable one
>> top of other in any order if not dependent), and it should work fine.
>> That way, we can handle more review load in future.
>
> When a regression fails how do you know who to blame?

We test multiple patches (say 10) at a time; fall back to previous model 
of one test per patch when regression fails (we can also employ binary 
search to find the patch causing the regression failure). Isn't this 
plausible?

- Varun Shastry
>
> I'd rather see more build machines (multiple VMs on a big 
> build.gluster.org replacement box?) instead to get more concurrency.
>
>





More information about the Gluster-devel mailing list