Re: CF3+4 (was Re: Parallel query execution)

2013/1/20 Simon Riggs <simon(at)2ndquadrant(dot)com>:
> On 20 January 2013 18:42, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sat, Jan 19, 2013 at 5:21 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers