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
greg@2ndQuadrant.com www.2ndQuadrant.com
