Re: Sampling profiler updated

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sampling profiler updated
Date: 2009-07-19 04:53:01
Message-ID: 603c8f070907182153j42fe75dbo46973ff905f41166@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 18, 2009 at 5:36 PM, Jaime
Casanova<jcasanov(at)systemguards(dot)com(dot)ec> wrote:
> On Sat, Jul 18, 2009 at 3:38 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>> On Sat, Jul 18, 2009 at 4:09 PM, Dimitri Fontaine<dfontaine(at)hi-media(dot)com> wrote:
>>> So I'm going to change patch state to "Returned with Feedback" as I guess
>>> we'll need to talk about the issue and find a way to solve it, and I don't
>>> think this state prevent from getting back to the patch in this same fest.
>>
>> In general I would prefer patches to be set to Returned with Feedback
>> only when we think they are probably done for this CommitFest.
>
> why? it seems very simple as is:
> Returned with Feedback means there is something to clean, when the
> author fixes the problem he can update it to Needs review.

No, that's what "waiting on author" means. "Returned with feedback"
means that it might be acceptable in some CommitFest, but not this
one. "Rejected" means we don't want it.

The distinction is important because it affects the review process.
If I have reviewed 8 patches and they are all in the status "waiting
on author", then I am reluctant to take on any more patches because I
might have to re-review as many as 8 patches, and that might be as
much (or more) than I'm prepared to take on. But if all of those
patches are returned with feedback, then I know that they are not
coming back, and I can take on a few more without worrying that I'm
suddenly going to get slammed by the need to re-review a bunch of
stuff.

It is also very hard to close the CommitFest if things that are dead
keep coming back to life again. To take an example, suppose that a
patch is reviewed on July 16th and the patch author is asked to make
some changes. Then, on August 10th, the author resubmits. If we take
the view that this is legitimate, then we're going to have a whole
slough of resubmits just prior to whatever we set as the last day for
resubmits, which will mean that the CommitFest is not going to be
closed in a month, and we need that to happen so that people can get
back to working on their own patches. What we need to say is if the
patch author can't resubmit within a few days (say, four, maybe a bit
more if it's a major patch or early in the CommitFest), then we move
it from waiting to author to returned with feedback and move on.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-07-19 08:00:49 Re: [PATCH] Psql List Languages
Previous Message Josh Berkus 2009-07-19 04:50:13 Re: multi-threaded pgbench