Re: Feature freeze progress report

Every patch in the queue is ready for review. If we have bounced
something back for the author to fix, it gets removed from the queue.

As far as adding comments, again, this wasn't meant to be a community
resource, just my tracking system, and I have given feedback on the
status to any committers who wants to know about a patch.

---------------------------------------------------------------------------

Heikki Linnakangas wrote:
> Tom Lane wrote:
> > [ thinks for a bit... ] What we need to expand is not so much the pool
> > of committers as the pool of reviewers. If a patch had been signed off
> > on by X number of reasonably-qualified people then it'd be fair to
> > consider that it could be committed. The tracking system you suggest
> > could make that sort of approach manageable.
>
> Agreed, committing a patch is not much work. If all the patches in the
> queue were perfect and just waiting for committing, one person could
> just commit them all in a day.
>
> What takes time is reviewing. We have people capable of reviewing
> patches, we should encourage them to do that (that includes myself).
> Maybe we should have a more official protocol of "signing-off" patches.
> And part of the review is refactoring and commenting and fixing tiny
> bugs that the original author missed. I've refrained from doing that
> myself because I'm afraid I'd step on the authors toes or joggle the
> elbow of a committer.
>
> One problem with the current patch queue is that it's really hard to get
> a picture of where each patch stands. There's many different reasons why
> a patch can get stalled in the patch queue. Looking at the patches there
> now:
>
> Design issues have been raised:
> - index advisor (messy API)
> - full page writes improvement, code update (increases WAL size)
> - dead space map (uses a fixed size shared memory block)
>
> Dependency on other patches:
> - scan-resistant buffer cache
> - group commit
> - error correction for n_dead_tuples
>
> Do we want this or not? -category
> - POSIX shared mem support
>
> Unfinished:
> - bitmap indexes
>
> Author is working on patch, based on comments
> - heap page diagnostic functions
> - load distributed checkpoint
>
> Author is waiting for feedback on how to proceed:
> - clustered indexes / grouped index tuples
> - concurrent psql patch
>
> (not exhaustive list, just examples)
>
> The above list reflects my view of the status of the patches. Others
> might not agree, and that's a problem in itself: it's not clear even to
> a patch author why a patch isn't moving forward. Author might think a
> patch is just about to be committed, while others are waiting for the
> author to fix an issue raised earlier. Or an author might think there's
> a problem with his patch, while it just hasn't been committed because of
> a dependency to another patch.
>
> If we had a 1-2 lines status blurp attached to each patch in the queue,
> like "waiting for review", "author is fixing issue XX", etc., that might
> help. Bruce would need to do that if we keep the current patch queue
> system unmodified otherwise, or we'd need to switch to something else.
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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