Re: ideas for auto-processing patches - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: ideas for auto-processing patches
Date
Msg-id 20070109114127.GI12217@nasby.net
Whole thread Raw
In response to Re: ideas for auto-processing patches  (Michael Glaesemann <grzm@seespotcode.net>)
Responses Re: ideas for auto-processing patches
List pgsql-hackers
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?

> (And isn't the version number  
> included in the patch if generated as a diff anyway?)

Of the patched files, yes... but that says little if anything about the
rest of the tree... unless the patch includes a file that is forced to
change every time there's a commit... but then the patch creator would
also have to change that file, which would create a mess. Yuck.

This is why associating a patch with a specific version of the tree
should definitely wait for version 2 of the patchfarm (or should it be
called the farmers patch? ;) ).
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: [BUGS] BUG #2873: Function that returns an empty set with a 'not null' domain errors in 8.2 but not 8.1
Next
From: "Andrew Dunstan"
Date:
Subject: Re: 8.3 pending patch queue