Re: Concurrent psql patch

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> 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
tracking.

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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