Re: 8.5 development schedule - Mailing list pgsql-hackers

On Wed, Jul 1, 2009 at 1:16 AM, Josh Berkus<josh@agliodbs.com> wrote:
> Hmmm ... actually, I think Andrew's right that we don't need a specific
> "last commitfest" rule which is special.  Really, any patch which gets
> submitted to any commitfest gets returned if it's not ready to be committed
> immediately after review.  The only way the last CF is special is that
> anything bounced goes to the next version.
>
> We forgot that with the November CF, which is why it dragged on for 3.5
> months and burned a lot of people out.   Let's just stick to that this time
> and we don't need any new rules.

Ugh, I disagree.  I agree that we were too generous with letting
people rework patches while the CommitFest was in progress (mostly, we
let people drop off the map for 3 weeks and then come back and say,
oh, here's my revised version).  But you have to allow a certain
amount of reworking as the CommitFest progresses, I think.  Otherwise,
it just takes way too long to get anything done.

Suppose someone submits a patch that has minor issues to the first
CommitFest.  The reviewer points the issues he sees, so the author
fixes the patch up and resubmits to the second CommitFest.  The patch
is now assigned for review again (possibly to a different reviewer),
and one more minor issue is discovered, so the author fixes up the
patch again and resubmits to the third CommitFest.  Upon third review,
it's discovered that one of the comments is poorly written, so the
author fixes it up again and resubmits to the final CommitFest,
whereupon it is committed.  That's about 7 months to get that patch
committed, and it would be twice that if the initial commitfest was to
the SECOND commitfest rather than the first, since the release cycle
would intervene.

What should actually happen is that the whole thing should be handled
by a single reviewer during one CommitFest.  It's much easier to
re-review a patch that you've read through just a few days prior than
it is to review a whole new patch from scratch, so I don't think it's
imposing an undue burden on the reviewers; in fact it should produce a
net REDUCTION in work by concentrating all the work for a particular
patch into a relatively compact period of time.  What WAS a big
problem during the last CommitFest, at least for me, was resubmits
that didn't happen promptly.  I couldn't decide whether I should
continue starting to review new patches, or whether that would lead to
chaos when all the resubmits from the ones I'd previously reviewed
came back around, leaving me with 4 or 5 patches that all needed to be
reviewed at the same time.  So I'm strongly in favor of a very firm
deadline for resubmits: except for very large patches like HS,
resubmits should be required within, say, 96 hours of the time the
review hits the list; otherwise, we bump it.

Basically, if we're too quick to bump patches to the next CommitFest,
there will be only moderate resistance for the first N-1 CommitFests,
but then for the last CommitFest people won't want to be bumped by a
whole major release for what are basically minor issues.  So we'll be
back in a situation where the last CommitFest is the pits.  We have to
find a middle ground where we're bumping things that are truly holding
things up (tying up reviewer resources or unduly lengthening the
CommitFest) but at the same time avoid bumping things so quickly that
we don't really provide a patch authors with a fair shake at getting
something committed in a reasonable period of time.

...Robert