[Gluster-devel] [Feature request]: Regression to take more patches in single instance

[Kaleb S. KEITHLEY]

On 07/31/2013 07:51 AM, Anand Avati wrote:
> On Wed, Jul 31, 2013 at 4:47 AM, Kaleb S. KEITHLEY <kkeithle at redhat.com
> <mailto:kkeithle at 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?

-- 

Kaleb