Bruce Momjian wrote:
So, if someone writes a patch, and it is reviewed, and the patch author
updates the patch and replies, it still should be reviewed again before
being committed?
That's generally how things were expected to happen--to at least double-check that the proposed fixes match what was expected. I don't think it was spelled out very well in the past though.

Also, we are two weeks into the commit fest and we have more unapplied
patches than applied ones.
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.

--
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com  www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to