Re: ideas for auto-processing patches

From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ideas for auto-processing patches
Date: 2007-01-06 05:02:32
Message-ID: 1948.24.211.165.134.1168059752.squirrel@www.dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>> Jim Nasby wrote:
>>> More important, I see no reason to tie applying patches to pulling
>>> from CVS. In fact, I think it's a bad idea: you want to build just
>>> what's in CVS first, to make sure that it's working, before you start
>>> testing any patches against it.
>
>> Actually, I think a patch would need to be designated against a
>> particular
>> branch and timestamp, and the buildfarm member would need to "update" to
>> that on its temp copy before applying the patch.
>
> I think I like Jim's idea better: you want to find out if some other
> applied patch has broken the patch-under-test, so I cannot see a reason
> for testing against anything except branch tip.
>
> There certainly is value in being able to test against a non-HEAD branch
> tip, but I don't see the point in testing against a back timestamp.
>

OK, if the aim is to catch patch bitrot, then you're right, of course.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2007-01-06 08:51:10 Re: -f <output file> option for pg_dumpall
Previous Message Tom Lane 2007-01-06 04:57:53 Re: A patch to pg_regress for Windows port