Re: CommitFest status/management - Mailing list pgsql-hackers

From Robert Haas
Subject Re: CommitFest status/management
Date
Msg-id 603c8f070912010350g58ddca9bn5aac5f534c6cce53@mail.gmail.com
Whole thread Raw
In response to Re: CommitFest status/management  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
On Mon, Nov 30, 2009 at 10:16 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Considering that one of those was a holiday week with a lot of schedule
> disruption proceeding it, I don't know how much faster things could have
> moved.  There were large chunks of the reviewer volunteers who wanted only
> jobs they could finish before the holiday, and others who weren't available
> at all until afterwards.  And I don't know about every else, but I took all
> four days off and started today behind by several hundred list messages.  I
> was planning to start nagging again tomorrow, hoping that most would be
> caught up from any holiday time off too by then.
>
> Right now, of the 16 patches listed in "Needs Review" besides the ECPG ones
> Michael is working through, the breakdown is like this:
>
> Not reviewed at all yet:  6
> Reviewed once, updated, waiting for re-review:  10
>
> So the bulk of the problem for keeping the pipeline moving is in these
> re-reviews holding up transitions to "Ready for committer".  I've had some
> discussion with Robert about how to better distinguish in the management app
> when the reviewer has work they're expected to do vs. when they think
> they're done with things.  We're converging toward a more clear set of
> written guidelines to provide for managing future CommitFests as part of
> that, right now there's a few too many fuzzy parts for my liking.
>
> If the need here is to speed up how fast things are fed to committers, we
> can certainly do that.  The current process still favors having reviewers do
> as much as possible first, as shown by all the stuff sitting in the
> re-review queue.  The work we're waiting on them for could be done by the
> committers instead if we want to shorten the whole process a bit.  I don't
> think that's really what you want though.

I think the pressure has to be applied all through the process.
People who haven't provided a review by now are certainly overdue for
a polite poke, Thanksgiving or no Thanksgiving.  If the first review
doesn't happen until the third week of the CommitFest, how is the
patch going to get a fair shake by the end of the fourth one?  I mean,
if that happens to a small number of patches, OK, but when it's 20% of
what's in the CommitFest, it seems like it's bound to lead to a huge
crunch at the end.

In any case, unlike last CommitFest, where the problem was a lack of
adequate committer activity, it's pretty clear that the the problem
this CommitFest has been a combination of slow reviews and slow
updates by patch authors.  I've been keeping a loose eye on the patch
queue and my impression is that there has rarely been more than 1
patch other than HS + SR in the "Ready for Committer" state, and many
times zero.  That's means the pipeline is stalling, and that's bad.

...Robert


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Block-level CRC checks
Next
From: Brar Piening
Date:
Subject: Re: Application name patch - v4