Re: Recovery Test Framework

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recovery Test Framework
Date: 2009-01-13 01:42:24
Message-ID: 200901130142.n0D1gOo09668@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark wrote:
> > Now, maybe this is unfair to patches that are frequently updated, but
> > this is the typical process we follow, and it explains why the patches
> > above have not gotten near commit status yet.
>
> It's not just "unfair". It's counter-productive. It means you're ignoring the
> very patches whose authors are mostly likely to be responsive to requests to
> change them. And who would be most likely to be fertile ground for further
> improvements.
>
> Perhaps it would be useful for you to understand how it looks from a
> submitter's point of view. As long as the patch sits in limbo only minor
> tweaks and refinements are worth bothering with. Any thoughts of continuing on
> any subsequent phases of development are all crushed since all that work might
> go down the drain when the committer makes changes to the code it's based on.

I am just explaining how it works in practice. If the patch is still
being improved, the feeling is that the author wants more time to adjust
things, and with other things on our plate, we are glad to leave their
patch until last.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-01-13 01:46:43 Re: Recovery Test Framework
Previous Message Robert Haas 2009-01-13 01:34:32 Re: Recovery Test Framework