Re: ideas for auto-processing patches

From: Michael Glaesemann <grzm(at)seespotcode(dot)net>
To: Jim C(dot)Nasby <jim(at)nasby(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ideas for auto-processing patches
Date: 2007-01-10 23:04:41
Message-ID: C48D3265-85B6-45E7-998A-9670837B76CE@seespotcode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Jan 9, 2007, at 20:41 , Jim C. Nasby wrote:

> On Mon, Jan 08, 2007 at 10:40:16PM -0600, Michael Glaesemann wrote:
>>
>> On Jan 8, 2007, at 19:25 , Jim C. Nasby wrote:
>>
>>> Actually, I see point in both... I'd think you'd want to know if a
>>> patch
>>> worked against the CVS checkout it was written against.
>>
>> Regardless, it's unlikely that the patch was tested against all of
>> the platforms available on the build farm. If it fails on some of the
>> build|patch farm animals, or if it fails due to bitrot, the point is
>> it fails: whatever version the patch was generated against is pretty
>> much moot: the patch needs to be fixed.
>
> Wouldn't there be some value to knowing whether the patch failed
> due to
> bitrot vs it just didn't work on some platforms out of the gate?

I'm having a hard time figuring out what that value would be. How
would that knowledge affect what's needed to fix the patch?

Michael Glaesemann
grzm seespotcode net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2007-01-10 23:10:39 Re: installcheck vs regression DLLs
Previous Message Tom Lane 2007-01-10 23:00:13 Re: installcheck vs regression DLLs