Re: Feature freeze progress report

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