2013/1/20 Simon Riggs <si...@2ndquadrant.com>: > 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.
+1 Pavel > > -- > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
