Skip site navigation (1) Skip section navigation (2)

Re: Review request: XLogInsert

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: "pgsql-rrreviewers(at)postgresql(dot)org" <pgsql-rrreviewers(at)postgresql(dot)org>
Subject: Re: Review request: XLogInsert
Date: 2009-12-06 23:42:43
Message-ID: 603c8f070912061542v794701edpa84f4e979d65ff11@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-rrreviewers
On Sun, Dec 6, 2009 at 12:18 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Robert Haas wrote:
>>
>> Not to distract from the issue at hand, but that goal doesn't seem quite
>> aggressive enough, considering that this is the last week of the CommitFest,
>> or near enough.  Do you have a plan for wrapping this up?
>
> To step back for a second, the fact that I have to create a plan shows a
> failure in our getting this turned into a real process.  That what I've been
> trying to do here--step back each week and figure out what I should have
> done, and try to make it more likely that will happen the next time.  We
> should have a clear plan charted that says what will happen at each step
> here.

I made an effort to document this in the section of the "Running a
CommitFest" page that is entitled "Followup, Followup, Followup".  But
that effort may not have been as successful as might have been wished,
and I apologize for that, welcome your efforts to rectify the
situation, and wish to help if I can.

> It looks to me like the end of the previous CF work finished via a huge
> amount of "patch chasing" work from you and possibly other helpers (I don't
> know, as I haven't gotten any such help myself the last few weeks).  That
> was fine since you were blazing a trail here, but that's not a sustainable
> model.  This whole thing needs clear written deadlines and process if it's
> going to run more automatically in the future.  CF manager and helper labor
> isn't easy to find an unlimited amount of.  I'd like to turn this all into
> something more like a state machine whose transitions are marked out on the
> calendar from day one.

I'm not sure that's going to be possible, but I certainly think that
reducing the amount of labor involved is a good goal.

> At around three weeks, where we're at now, I think what should happen next
> is:
>
> 1) All "waiting for author patches" turn into "returned with feedback" as of
> some deadline.  Since there wasn't one in advance, maybe I announce one on
> the hackers list today?

In general, I think that the deadline for Waiting for Author patches
to move to Returned with Feedback should be based on when the review
happened + 5 days (maybe 4 days during the second half of the
CommitFest, or if the patch has been re-reviewed).  If someone gets a
review at the beginning of the CommitFest, they should update their
patch within a few days of the review.  They shouldn't get two extra
weeks to update their patch because they were lucky enough to get an
early review.  On the other hand, someone who doesn't get a review
until later should get a reasonable time to respond if there's any
chance the patch can be fixed up quickly.

So there are a number of patches that I think we should mark as RWF
immediately, just because a lot of time has gone by:

PL/Python array support
Python 3.1 support
Memory management probes
Listen / Notify rewrite

For the rest, I agree that publishing a deadline on -hackers today is
a good idea.  I don't think we can afford to give people much more
time, though: say until Tuesday, when there will be a week remaining
in the CF.

> 2) Poll the reviewer of every patch that's had an updated version who hasn't
> submitted a re-review asking whether they think that version is "ready for
> comitter" now, if they have more feedback, or if they feel it's just not
> ready yet and should be rejected.  In any case but "ready for committer", it
> goes into "returned with feedback" pile.

Agreed.

> 3) Any patches in this state that we haven't heard back from the reviewer on
> within a couple of days get decided on ("ready" / "returned") at the
> CommitFest manager's discretion.  If anyone feels wronged by that, they can
> always ask that a committer take a look anyway.  The CF manager won't always
> have as much information as we expect the reviewers to, and can be presumed
> to have a thicker skin about people getting mad at them for making a bad
> decision too.

Yeah, that's pretty much what I've been doing.

> I have a deliverable to ship today, once I'm done with that I'll start
> rattling people more.  Feedback about tweaking the above before I start
> executing on it would be appreciated.

I have some time tonight I'd be willing to put into taking a sweep
through the patch queue, if you'd like me to take a swing at it.  If
not, that's OK too.  I can't tell you how much I appreciate all the
work you've done so far.  I really needed a break, and am feeling
infinitely better for it.

...Robert

In response to

Responses

pgsql-rrreviewers by date

Next:From: Greg SmithDate: 2009-12-07 00:10:54
Subject: Re: Review request: XLogInsert
Previous:From: Greg SmithDate: 2009-12-06 17:18:07
Subject: Re: Review request: XLogInsert

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group