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

[Anand Avati]

On Wed, Jul 31, 2013 at 5:09 AM, Kaleb S. KEITHLEY <address@hidden> wrote:

On 07/31/2013 07:51 AM, Anand Avati wrote:

On Wed, Jul 31, 2013 at 4:47 AM, Kaleb S. KEITHLEY <address@hidden

<mailto:address@hidden>> 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