On Wed, Jul 31, 2013 at 4:47 AM, Kaleb S. KEITHLEY <kkeit...@redhat.com>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? > > I'd rather see more build machines (multiple VMs on a big > build.gluster.org replacement box?) instead to get more concurrency. We already face that ambiguity when a patch has a dependent patch. Multiple VMs will solve the problem, but I guess we need to figure out how to get a bigger box etc. Avati
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
