On Mon, Mar 04, 2013 at 01:59:31PM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Sun, Mar 3, 2013 at 9:27 PM, Josh Berkus <josh@agliodbs.com> wrote:
> >> Except that the implication of "waiting on author" is that, if there's
> >> no updates in a couple weeks, we bounce it. And the author doesn't
> >> necessarily control a bikeshedding discussion about syntax, for example.
>
> > That's true. I think, though, that the basic problem is that we've
> > lost track of the ostensible purpose of a CommitFest, which is to
> > commit the patches that *are already ready* for commit.
>
> Mumble. That's *part* of the purpose of a CF, but not all. It's also
> meant to be a time when people concentrate on reviewing patches, and
> surely discussions about syntax or whatever have to be part of that.
The distinction I recall arising from discussions about this time last year is
that we should review all submissions but only iterate within the CF on
patches that are about ready. In other words, a process like this:
Review a patch in "Needs Review". Write up any problems in a reply to the submission. Problems are absent or trivial?
Mark patch Ready for Committer. Problems are few or isolated? Mark patch Waiting on Author. Problems are many or
fundamental? Mark patch Returned with Feedback.
The current process typically looks more like this:
Review a patch in "Needs Review". Write up any problems in a reply to the submission. Problems are absent or trivial?
Mark patch Ready for Committer. CommitFest is too long overdue? Mark patch Returned with Feedback. Else, mark patch
Waitingon Author.
(I've left out state transitions initiated by the patch author, rejection-type
decisions, and probably other things.)
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
