Bruce Momjian <br...@momjian.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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
