Re: ideas for auto-processing patches

From: Richard Troy <rtroy(at)ScienceTools(dot)com>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: Michael Glaesemann <grzm(at)seespotcode(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ideas for auto-processing patches
Date: 2007-01-11 01:35:41
Message-ID: Pine.LNX.4.33.0701101727260.12656-100000@denzel.in
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Wed, 10 Jan 2007, Jim C. Nasby wrote:
>
> On Thu, Jan 11, 2007 at 08:04:41AM +0900, Michael Glaesemann wrote:
> > >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?
>
> I was thinking that knowing it did work at one time would be useful, but
> maybe that's not the case...
>

"Has it ever worked" is the singularly most fundamental technical support
question; yes, it has value.

One question here - rhetorical, perhaps - is; What changed and when? Often
when things changed can help get you to what changed. (This is what logs
are for, and not just automated computer logs, but system management
things like, "I upgraded GCC today.") And that can help you focus in on
what to do to fix the problem. (such as looking to the GCC release notes)

A non-rhetorical question is; Shouldn't the build process mechanism/system
know when _any_ aspect of a build has failed (including patches)? I'd
think so, especially in a build-farm scenario.

...Just my two cents - and worth every penny! -smile-

Richard

--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy(at)ScienceTools(dot)com, http://ScienceTools.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2007-01-11 01:36:25 Re: Request for review: tsearch2 patch
Previous Message Jim C. Nasby 2007-01-11 01:23:55 Re: table partioning performance