Re: ideas for auto-processing patches

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
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:03:18
Message-ID: Pine.LNX.4.58.0701111158390.30975@linuxworld.com.au
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...

It might be useful to patch authors who submit code which remains
unreviewed for some time. Then the submitter or reviewer will be able to
know at what date the code drifted. This might be easier than looking
through the commit history and trying to locate the problem, I think.

Still, the more interesting thing to me would be to be able to provide in
the patch a set of custom tests inside of the regression test frame work
which aren't suitable as RTs in the long term but will be able to tell the
patch author if their code works correctly on a variety of platforms.

Thanks,

Gavin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2007-01-11 01:23:55 Re: table partioning performance
Previous Message Jim C. Nasby 2007-01-11 00:58:48 Re: Added the word TODO in comments