On 04/05/2012 05:03 PM, Daniel Farina wrote:
To get to the point, I wonder if it makes sense for someone who has a better sense a-priori what they're looking for in a committable patch (i.e. a committer, or someone with a telepathic link to one or more) to delegate specific pieces of patches for thorough review, sketching some thoughts about pitfalls or hazards to look for. Think of it as a patch checklist that is informed by the experience of a committer skimming its contents.
It's tricky to add this sort of idea into the current patch workflow in all cases. A decent percentage of submissions bounce off a reviewer who doesn't commit, such that no committer spends time on them yet they still move forward. Any idea that tries to involve committers earlier in the process risks using more of their time on things that ultimately are never going to pass toward commit anyway. That is after all where this whole process started at, before CFs, and we know that didn't scale well.
We already have a loose bar in this exact area, one that suggests larger patches should first appear earlier in the development cycle. That happened in this case, with a first submission in mid November, but it wasn't enough to make things go smoothly.
When I trace back how that played out, I think the gap in this case came from not being sure who was going to commit the result at the end. If it's early January, and the community knows there's a large feature approaching because it's been around for over a month already, we better be asking who is going to commit it eventually already. Many patch submitters agonize over "which committer is going to grill me most?", and the bigger the patch the more that impacts them.
Nailing that down and putting together the sort of early committer checklist you're describing strikes me as something that might happen in the first week of a CF, before there are normally a large pile of "Ready for Committer" things around. Raising these question--who is interesting in committing big things and where they consider the bar to be--is something submitters who have a stake in seeing their patches go on might do.
It's better if people who are already working hard on features don't feel like they need to wander around begging for someone to pay attention to them though. Ideally it would be the sort of thing a proper CF manager would highlight for them. Unfortunately we often don't quite have one of those, instead just having people who sometimes make a bunch of noise at the beginning of a CF and then go AWOL. (cough) No one is happy about that, and it's something that clearly needs to be solved better too.
-- Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support 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
