gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] [Feature request]: Regression to take more patches i


From: Niels de Vos
Subject: Re: [Gluster-devel] [Feature request]: Regression to take more patches in single instance
Date: Fri, 2 Aug 2013 11:50:38 +0200
User-agent: Mutt/1.5.20 (2009-12-10)

On Fri, Aug 02, 2013 at 02:02:34PM +0530, Varun Shastry wrote:
> 
> 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?

In fact, this can be automated pretty easily with 'git bisect'. It seems 
that there is a feature request for Jenkins already:
- https://issues.jenkins-ci.org/browse/JENKINS-12972

I have no idea about the internals of Jenkins, so I can not really help 
with pushing this.

Cheers,
Niels


> 
> - Varun Shastry
> >
> >I'd rather see more build machines (multiple VMs on a big
> >build.gluster.org replacement box?) instead to get more
> >concurrency.
> >
> >
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel

-- 
Niels de Vos
Sr. Software Maintenance Engineer
Support Engineering Group
Red Hat Global Support Services



reply via email to

[Prev in Thread] Current Thread [Next in Thread]