Horton

Re: Draft release notes complete

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>, Alvaro Herrera <alvherre@commandprompt.com>, PeterEisentraut <peter_e@gmx.net>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-05-12T13:27:16Z
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

In summary, names on release note items potentially have the following
beneficial effects:

*  Encouraging new developers/reviewers
*  Encouraging long-established developers
*  Showing appreciation to developers
*  Assisting future employment for developers
*  Helping developers get future funding
*  Assigning responsibility for features
*  Assigning blame for feature problems
*  Showing Postgres's increased developer base

Many of these goals has already been mentioned.  So the question is
which of these is important?  If we emphasize all of them, I am afraid
the name list for each item will be too long to be acceptable.  

How many names on a single item is ideal?  The activity of reviewers and
their names on commit messages has greatly expanded the number of
potential names per item.

How much of a downside is having the names in the release notes?  For
example, we decided that company names shouldn't be on release note
items, so there is a case where we decided names were more of a negative
than a positive.  Are there other negatives?  Do other project release
notes have developer names?  How are these names perceived by our
general readers?

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

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