On Mon, Nov 30, 2009 at 10:16 PM, Greg Smith <greg(at)2ndquadrant(dot)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.
In response to
pgsql-hackers by date
|Next:||From: Euler Taveira de Oliveira||Date: 2009-12-01 11:52:08|
|Subject: Re: ProcessUtility_hook|
|Previous:||From: Bruce Momjian||Date: 2009-12-01 11:35:42|
|Subject: Re: Block-level CRC checks|