From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Michael Glaesemann <grzm(at)seespotcode(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-09 11:41:27 |
Message-ID: | 20070109114127.GI12217@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-01-09 12:48:52 | Re: table partioning performance |
Previous Message | Jim C. Nasby | 2007-01-09 11:36:04 | Re: [HACKERS] BUG #2873: Function that returns an empty set with a 'not null' domain errors in 8.2 but not 8.1 |