Re: Schedule for 8.5 Development

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Schedule for 8.5 Development
Date: 2009-09-03 02:35:53
Message-ID: 603c8f070909021935s141fca67q29b3af0b68ad9677@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 2, 2009 at 10:22 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> Robert,
>
>> A. Update the status of patches on the wiki (because the patch authors
>> and reviewers often didn't).
>> B. Poke reviewers or patch authors who didn't respond in a timely
>> fashion and/or move to "Returned with Feedback".
>> C. Assign new patches to reviewers who requested them.
>> D. Send occasional status updates to -hackers.
>>
>> I think that the burden on the CM could be greatly reduced if patch
>> authors and reviewers could try to make sure to do (A) and (B)
>> themselves as much as possible.  (C) and (D) are really not much work.
>
> Couldn't (B) be done by the app?  If you recall, I suggested a while ago
> that the app ought to auto-email reviewers and authors after a few days
> of inactivity, and then alert you if they don't respond after a couple
> days more.

I think it needs a little more of a human touch than that. Beyond the
fact that people tend to pay more attention to an email from a person
than an automatically generated one, there's value in giving voice to
the specific issues with that particular patch... "It sounds like
this needs too much reworking for this CF" is different from "Are you
planning to update this patch based on so-and-so's review?" which in
turn is different from "So-and-so, are you planning to do any
additional review of this patch?".

> Anyway, I can easily see dividing the duties of assigning patches to
> reviewers and keeping status updated.

I think it would be more valuable to divide up the task of keeping
status updated, maybe by CommitFest topic. Assigning the patches is
not very time-consuming. But on that note, one thing I tried to do
(not sure how well I succeeded) last time is tried to match patches
with reviewers both by patch topic and level of experience, with a
bias toward getting large patches reviewed early. I found this to be
one of the trickier parts of the whole project, because I obviously
had to assign reviewers without having read most of the patches or
with only limited knowledge of the capabilities and interests of the
reviewers. Still, I must have done OK, because it worked out. What's
unclear to me is how much value I added in the process, and how much
better or worse things could have gone had I made different decisions.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2009-09-03 02:47:37 Re: Triggers on columns
Previous Message Itagaki Takahiro 2009-09-03 02:30:24 Re: Triggers on columns