Re: Credit in the release notes WAS: Draft release notes complete

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>

To: Andrew Dunstan <andrew@dunslane.net>

Cc: Josh Berkus <josh@agliodbs.com>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@commandprompt.com>, PeterEisentraut <peter_e@gmx.net>, Pg Hackers <pgsql-hackers@postgresql.org>

Date: 2012-05-13T01:35: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 →

Expose track_iotiming information via pg_stat_statements.
- 5b4f34661143 9.2.0 cited
Rewrite GiST support code for rangetypes.
- 80da9e68fdd7 9.2.0 cited
Clean up a couple of box gist helper functions.
- d50e1251946a 9.2.0 cited
Replace the "New Linear" GiST split algorithm for boxes and points with a
- 7f3bd86843e5 9.2.0 cited

On Sat, May 12, 2012 at 09:27:21PM -0400, Andrew Dunstan wrote:
> >Should we go with a single developer per item, and then let people
> >suggest corrections?  With reviewers involved, and often multiple commit
> >messages per release note item, the just isn't enough detail in git logs
> >to reproduce this accurately.  I also over-emphasized new
> >developers/reviewers, but that seems to have distorted the other goals
> >unacceptably.
> 
> Most cases should be pretty clear. Most features have a single major
> commit. The author(s) mentioned there are who should be listed,
> IMNSHO. That might leave a handful of cases where more judgement is
> required.
> 
> We seem to be in danger of overthinking this.

Results have just shown it isn't a simple case.  It is unclear how
important the reviewers were, and how much a committer rewrote the
patch, and the significance of follow-on commits.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +