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: | 603c8f070912010350g58ddca9bn5aac5f534c6cce53@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira de Oliveira | 2009-12-01 11:52:08 | Re: ProcessUtility_hook |
Previous Message | Bruce Momjian | 2009-12-01 11:35:42 | Re: Block-level CRC checks |