<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 31, 2013 at 5:09 AM, Kaleb S. KEITHLEY <span dir="ltr"><<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a>></span> wrote:<br>
<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:51 AM, Anand Avati wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Wed, Jul 31, 2013 at 4:47 AM, Kaleb S. KEITHLEY <<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a><br></div><div class="im">
<mailto:<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a>>> wrote:<br>
<br>
On 07/31/2013 07:35 AM, Amar Tumballi wrote:<br>
<br>
Hi,<br>
<br>
I was trying to fire some regression builds on very minor<br>
patches today,<br>
and noticed (always known, but faced pain of 'waiting' today)<br>
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<br>
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<br>
in code<br>
contribution. Would be great to have an option to submit<br>
regression run<br>
with multiple patch numbers, (technically they should be<br>
applicable one<br>
top of other in any order if not dependent), and it should work<br>
fine.<br>
That way, we can handle more review load in future.<br>
<br>
<br>
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<br></div>
<a href="http://build.gluster.org" target="_blank">build.gluster.org</a> <<a href="http://build.gluster.org" target="_blank">http://build.gluster.org</a>> replacement box?)<div class="im"><br>
instead to get more concurrency.<br>
<br>
<br>
We already face that ambiguity when a patch has a dependent patch.<br>
</div></blockquote>
<br>
That's a bit of a special case. The dependent patch is often owned by the same person, right? I would not want to make this harder for people in the general case.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Multiple VMs will solve the problem, but I guess we need to figure out<br>
how to get a bigger box etc.<br>
<br>
</blockquote>
<br></div>
Can the "slave" build machines be behind a firewall? I'm working on getting the old Sunnyvale lab machines on-line in our new lab. Can we use some of those?</blockquote><div><br></div><div>That should work, I think!</div>
<div><br></div><div>Thanks,</div><div>Avati</div><div> </div></div></div></div>