Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > My understanding was that all items in a commit-fest have one of these 
> > three dispositions:
> > . committed
> > . rejected
> > . referred back to author for more work
> Right.  But Bruce's personal queue has got a different lifecycle:
> items get removed when they are resolved by a committed patch, or
> by being rejected as not wanted, or by being summarized on the public
> TODO list.  For what he's doing that's a very good definition ---
> things don't get forgotten just because nothing has happened lately.
> But it's becoming clearer to me that the commit-fest queue has to be
> a separate animal.  We used Bruce's queue as the base this time around,
> because we had no other timely-available source of the raw data.
> Seems like it's time to split them, though.

Right, if the patch author stops working on it, but it is a feature we
want, the thread goes on the TODO list (or we complete the patch), so
yes, it is a different life-cycle.

> If we do split them then there is going to be some added effort to
> maintain the commit fest queue.  Bruce has made it pretty clear
> that he doesn't want to put in any extra cycles here.  So someone
> else has to step up to the plate if this is going to work.
> Any volunteers out there?

I assumed the wiki was going to be the official patch list from now on
and my web pages were just going to be a public display of things I was

Frankly, I haven't been putting anything on the queue for the next
commit fest now except stuff that was already in-process for this commit
fest.  The ideas is that we can commit stuff that has appeared since the
commit fest started before the next commit fest starts.  I also moved
the emails to the next commit fest queue because that preserves the
comments made too.

  Bruce Momjian  <[EMAIL PROTECTED]>

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

Sent via pgsql-patches mailing list (
To make changes to your subscription:

Reply via email to