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-07 01:25:48
Message-ID: 603c8f070912061725k79933424t6ea7d292c49b51a4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-rrreviewers

On Sun, Dec 6, 2009 at 7:10 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Robert Haas wrote:
>>
>> 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
>
> All that documentation was a big help for getting started.  The main problem
> with how you were chasing after things is that I think it was a bit too
> patch-specific.  The parts that we still need to work on are more related to
> overall time flow.  For example, I'd prefer to see some hard date guidelines
> for when exactly to start really aggressively booting patches out, rather
> than the useful but somewhat fuzzy ones you've got listed there now.

Fair enough. I'm not going to deny that my approach to this is fairly
hands-on and informal, and making heavy use of intuition. It would be
nice to tighten that up a bit and try to write out that intuition as a
set of more formal guidelines.

> The idea of giving every individual patch its own timetable is fair but very
> time intensive.  I think we'll have much better luck at getting other people
> to do this job if it's chunked into a task checklist you run through once or

Well, if the task list is - bug people who have had their patch
reviewed but haven't updated it, that can work. But I'm firmly of the
opinion that any system where there is a global timetable for all
patches is doomed to failure. That will inevitably lead to a crush of
people resubmitting just before that deadline, which will lead to a
committer crunch later on. You have to look at the whole thing as a
pipeline that constantly keeps reviewers, patch authors, and
committers busy, without ever piling too much on any one group while
the others sit idle. (Of course, at the end, things tend to build up
a little on the committer end of things, but you want to try to
minimize that by getting as much stuff as possible Ready for Committer
earlier on.)

...Robert

In response to

Browse pgsql-rrreviewers by date

  From Date Subject
Next Message Greg Smith 2009-12-07 04:55:47 Re: Review request: XLogInsert
Previous Message Greg Smith 2009-12-07 00:10:54 Re: Review request: XLogInsert