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: