Re: marking old branches as no longer maintained - Mailing list pgsql-hackers

From Dave Page
Subject Re: marking old branches as no longer maintained
Date
Msg-id BANLkTimgqXMQ1=sP1nTY2xK2eJyRH+=CoA@mail.gmail.com
Whole thread Raw
In response to Re: marking old branches as no longer maintained  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: marking old branches as no longer maintained
List pgsql-hackers
On Tuesday, June 28, 2011, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 06/28/2011 03:17 PM, Dave Page wrote:
>
> On Tue, Jun 28, 2011 at 8:02 PM, Magnus Hagander<magnus@hagander.net>  wrote:
>
> If we can find a good way to do it, I think having BF animals
> automatically picking up new branches is a very good thing to have. So
> don't give up so easily :D If adding a more or less random file to
> back branches is the only way to do it, I'm for doing that - I'd just
> like to find some method that feels cleaner. But maybe I'm just
> bikeshedding for no real use here.
>
> Adding new branches automatically would be great, but it'll need some
> work from the animal herders as well as some careful design - for
> example, my Windows animals have separate schedules for each branch
> (some running more frequently than others), whilst my Solaris ones now
> use a runner script that cycles through the list of branches on each
> of a couple of animals.
>
>
> Modern buildfarm code has a wrapper builtin. So my crontab usually just looks like this:
>
>    27 * * * * cd bf && ./run_branches.pl --config=nightjar.conf --run-all
>
> The buildfarm.conf has a section like this:
>
>    if ($branch eq 'global')
>    {
>         $conf{branches_to_build} = [qw( HEAD REL9_1_STABLE
>    REL9_0_STABLE REL8_4_STABLE REL8_3_STABLE REL8_2_STABLE)];
>    }
>
> What I'd like to do is to allow this to read:
>
>    if ($branch eq 'global')
>    {
>         $conf{branches_to_build} = 'ALL';
>    }
>
> and have it choose the right set for you.

Oh, cool. Guess I'll be reconfiguring my animals soon :-)

> But if you want to run some more frequently you'd still be stuck having to manage that yourself. There's actually not
alot of point in doing it that way, though. We don't build unless there have been changes on the branch, unless told
otherwise,so you might as well run frequently and test all the branches - for the most part only HEAD (i.e. master)
willbe built because it gets far more changes than the back branches. 

It was something Tom asked for ages ago, so he could see if the
Windows build got broken more promptly. I didn't want multiple
branches running with increased frequency as I run a number of animals
on a single machine with vmware, and a back patched change could cause
a lot of extra work.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Avoid index rebuilds for no-rewrite ALTER TABLE ALTER TYPE
Next
From: Andrew Dunstan
Date:
Subject: Re: marking old branches as no longer maintained