<div dir="ltr">On Wed, Jul 31, 2013 at 4:47 AM, Kaleb S. KEITHLEY <span dir="ltr"><<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 07/31/2013 07:35 AM, Amar Tumballi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I was trying to fire some regression builds on very minor patches today,<br>
and noticed (always known, but faced pain of 'waiting' today) that we<br>
can fire regression build on only one patch (or a patchset if its<br>
submitted with dependency added while submitting). And each regression<br>
run takes approx 30mins.<br>
<br>
With this model, we can at max take only ~45 patches in a day, which<br>
won't scale up if we want to grow with more people participating in code<br>
contribution. Would be great to have an option to submit regression run<br>
with multiple patch numbers, (technically they should be applicable one<br>
top of other in any order if not dependent), and it should work fine.<br>
That way, we can handle more review load in future.<br>
</blockquote>
<br></div>
When a regression fails how do you know who to blame?<br>
<br>
I'd rather see more build machines (multiple VMs on a big <a href="http://build.gluster.org" target="_blank">build.gluster.org</a> replacement box?) instead to get more concurrency.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>Avati</div></div></div></div>