Re: Recovery Test Framework

Bruce Momjian <bruce(at)momjian(dot)us> writes:

> As for the process used, I think it is useful to understand how
> committers choose what to work on next. One criteria is that the patch
> has stabilized; if a patch is still be modified regularly, the
> committer might as well work on another patch that has stabilized. Now,
> a committer could ask for the patch to stabilize to work on it, but if
> he has other patches that are stable, there is no point in asking for a
> stable version; he might as well work on just stable ones until only
> unstable ones are left.
>
> 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.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!