On 20 January 2013 18:42, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Jan 19, 2013 at 5:21 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> Sometime this type of high-level summary review does happen, at the senior >> person's whim, but is not a formal part of the commit fest process. >> >> What I don't know is how much work it takes for one of those senior people >> to make one of those summary judgments, compared to how much it takes for >> them to just do an entire review from scratch. > > IME, making such summary judgements can often be done in a few > minutes, but convincing that the patch submitter that you haven't > created the objection purely as an obstacle to progress is the work of > a lifetime. We could perhaps do better at avoiding perverse > incentives, there.
(Without meaning to paraphrase you in any negative way...) Judgements made in a few minutes are very frequently wrong, and it takes a lot of time to convince the person making snap decisions that they should revise their thinking in light of new or correct information. I feel we are very prone to making judgements on little information. This is especially true with regard to voting, with people zooming in from the side without having even read a patch to vote one way or the other, voting for the person not the idea. It can be a big problem telling the difference between a patch submitter that really is in possession of information that should be heeded and someone so blinded by their patch/idea that they mistakenly push forwards. At times, I have been both and I've also witnessed both as committer. There is a clear and understandable conservatism in being a reviewer/committer that people that haven't done it don't understand. I definitely didn't until I was a committer and I remember clearly me pushing for HS to go into 8.4 when it was a long way from being ready. I think it would be useful to expand the pool of committers and perhaps that can be done via some intermediate stage, though I do worry that the sense of responsibility might not be as strong in the intermediate rank ($NAME). I don't think we should be encouraging people to make fast decisions. Senior or not. (Though we must make decisions and have some coming soon). This is high in my mind right now since I've been looking at skip checkpoint patch for months, seeing how I feel about it. Nervous, basically. >From that I think that some areas of the code are more critical than others and harder to fix in production if they go wrong. We need to be taking more care in critical areas and it would be useful to be able to mark a patch for its level of risk, rather than just "is it ready". That way we can gauge the risk/benefit. Examples of high risk would be checksums, examples of low risk would be logical replication patches. Anyway, some thoughts to discuss in May. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers