On Wed, Jul 31, 2013 at 5:09 AM, Kaleb S. KEITHLEY <kkeit...@redhat.com>wrote:
> On 07/31/2013 07:51 AM, Anand Avati wrote: > >> On Wed, Jul 31, 2013 at 4:47 AM, Kaleb S. KEITHLEY <kkeit...@redhat.com >> <mailto: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 <http://build.gluster.org> replacement box?) >> >> instead to get more concurrency. >> >> >> We already face that ambiguity when a patch has a dependent patch. >> > > 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. > > > Multiple VMs will solve the problem, but I guess we need to figure out >> how to get a bigger box etc. >> >> > 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? That should work, I think! Thanks, Avati
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
