Horton

Re: Draft release notes complete

Christopher Browne <cbbrowne@gmail.com>

View thread
From: Christopher Browne <cbbrowne@gmail.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Date: 2012-05-10T18:43:48Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Expose track_iotiming information via pg_stat_statements.

  2. Rewrite GiST support code for rangetypes.

  3. Clean up a couple of box gist helper functions.

  4. Replace the "New Linear" GiST split algorithm for boxes and points with a

On Thu, May 10, 2012 at 12:55 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 5/10/12 9:44 AM, Peter Eisentraut wrote:
>> On tor, 2012-05-10 at 10:44 -0400, Bruce Momjian wrote:
>>> The big take-away is that the release notes are mostly for blame and
>>> to designate a go-to person for feature problems, not for giving
>>> credit,
>>
>> Then reviewers should be removed.
>
> I disagree.  We're trying to get more reviewers, and encourage them to
> do more reviewing.  Giving credit is a big part of that.

As much as that's nice, I don't think that's quite enough reason to do
so, at least not as a last minute afterthought in trying to finalize
the release notes.

On the other hand, if reviewers are considered extra "go-to" people
for the purposes of 'blamecasting' if something goes wrong with a new
feature, that's actually a fine reason to include them.  If both the
developer *and* the reviewer missed an issue, then *both* are
"blameworthy," and if we have any features gone desperately wrong,
both deserve to have appropriate things thrown at them.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"