Skip site navigation (1) Skip section navigation (2)

Re: CommitFest status/management

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CommitFest status/management
Date: 2009-12-01 11:50:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 OliveiraDate: 2009-12-01 11:52:08
Subject: Re: ProcessUtility_hook
Previous:From: Bruce MomjianDate: 2009-12-01 11:35:42
Subject: Re: Block-level CRC checks

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group