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

- 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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to