Horton

Re: Draft release notes complete

Bruce Momjian <bruce@momjian.us>

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

I will make the adjustments outlined below as soon as I can.

---------------------------------------------------------------------------

On Sun, May 13, 2012 at 12:37:52AM -0400, Robert Haas wrote:
> On Sat, May 12, 2012 at 8:11 PM, Euler Taveira <euler@timbira.com> wrote:
> > On 12-05-2012 10:27, Bruce Momjian wrote:
> >> 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.
> >>
> > Main authors only. Reviewers should be mentioned only in the commit log. If I
> > coded a feature and Bruce got the idea worked in another patch (that is better
> > then mine), I think only Bruce should be credited in release notes (but I
> > could be mentioned in the commit log as the feature designer). However, if I
> > posted a patch and Robert improved that patch using only 30% of my work, I
> > should be credited (as coauthor) because he used a considerable part of my work.
> 
> Completely agreed.  If we're going to include names in the release
> notes, I agree that this is the way to do it, and I think it's what we
> have done in prior releases.
> 
> I tend to err on the side of crediting people in the commit message
> (of course, occasionally I forget someone who should have been
> included), but I also try to make it clear by the phrasing whose code
> got included and who contributed in some other way - e.g. by reporting
> the problem, coming up with the original idea, or reviewing.  I do
> this in part because I assumed that we'd use that as the criteria for
> including names in the release notes, as we have done in prior
> releases.  So if I write:
> 
> Euler Taveira, reviewed by Bruce Momjian, substantially rewritten by me
> 
> ...then I expect that to turn up in the release notes as (Euler
> Taveira, Robert Haas).  If I write:
> 
> Euler Taveira, reviewed by Bruce Momjian, with minor cleanup by me
> 
> ...then I expect that to turn up as (Euler Taveira).  And if I write
> something like:
> 
> Inspired by a patch from Euler Taveira.  Review (in earlier versions)
> by Bruce Momjian.
> 
> ...then I expect that to turn up as (Robert Haas) or (Robert Haas,
> Euler Taveira).
> 
> In doubtful cases, I think it's generally appropriate to err on the
> side of crediting the person who was the original driving force behind
> the patch, and also to err on the side of not crediting the committer.
>  But if the committer chopped up the patch and committed something
> significantly different from the original, then they should be
> credited - or blamed - for the result.
> 
> -- 
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

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

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