From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Last gasp |
Date: | 2012-04-09 23:38:16 |
Message-ID: | CA+TgmobrGWaatFbuMGJKL4J2AcJCaw3hF-37r8xmxHg7v98smw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 9, 2012 at 6:23 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> But objective rules do not require a just judge, and they have a
> different advantage: predictability. If I know that a clock starts ticking
> the moment I get my first review, I'll shape my personal plan accordingly.
> That works even if I don't favor that timer to govern CFs.
In theory this is true, but previous attempts at enforcing a
time-based rule were, as I say, not a complete success. Maybe we just
need greater consensus around the rule, whatever it is.
At any rate, I think your comments are driving at a good point, which
is that CommitFests are a time for patches that are done or very
nearly done to get committed, and a time for other patches to get
reviewed if they haven't been already. If we make it clear that the
purpose of the CommitFest is to assess whether the patch is
committable, rather than to provide an open-ended window for it to
become committable, we might do better.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-04-09 23:59:24 | Re: Last gasp |
Previous Message | Jeff Davis | 2012-04-09 23:12:12 | Re: bug in fast-path locking |