Re: Deriving release notes from git commit messages - Mailing list pgsql-hackers

On Fri, Jun 24, 2011 at 1:15 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> There's been a steady flow of messages on pgsql-advocacy since last month
> (threads "Crediting sponsors in release notes?" and "Crediting reviewers &
> bug-reporters in the release notes") talking about who/how should receive
> credited for their work on PostgreSQL.  That discussion seems to be me
> heading in one inevitable direction:  it's not going to be possible to make
> everyone happy unless there's a way to track all of these things for each
> feature added to PostgreSQL:

I don't read -advocacy regularly, but reviewing the archives, it
doesn't seem to me that we've reached any conclusion about whether
including this information in the release notes is a good idea in the
first place.  It seems to me that one name for each feature is about
at the limit of what we can reasonably do without cluttering the
release notes to the point of unreadability.  I am OK with it the way
it is, but if we must change it I would argue that we ought to have
less credit there, not more.  Which is not to say we shouldn't have
credit.  I think crediting sponsors and reviewers and bug reporters is
a good idea.  But I think the web site is the place to do that, not
the release notes.

As for annotating the commit messages, I think something like:

Reporter: Sam Jones
Author: Beverly Smith
Author: Jim Davids
Reviewer: Fred Block
Reviewer: Pauline Andrews

...would be a useful convention.  I am disinclined to add a "feature"
annotation.  I think it is unlikely that will end up being any more
useful than just extracting either the whole commit message or its
first line.

I am not inclined to try to track sponsors in the commit message at
all.  Suppose Jeff Davis submits a patch, Stephen Frost reviews it,
and I commit it.  Besides the three human beings involved,
potentially, you've got three employers who might be considered
sponsors, plus any customers of those employers who might have paid
said employer money to justify the time spent on that patch.  On a big
patch, you could easily have ten companies involved in different
roles, some of whom may have made a far larger real contribution to
the development of the feature than others, and I am 100% opposed to
making it the committer's job to include all that in the commit
message.   Also, unlike individuals (whose names can usually be read
off the thread in a few seconds), it is not necessarily obvious who
the corporate participants are (or which ones even WANT to be
credited).  It is almost certain that the committer will sometimes get
it wrong, and the commit log is a terrible place to record information
that might need to be changed after the fact.

It seems to me that, at least for sponsorship information, it would be
far better to have a separate database that pulls in the commit logs
and then gets annotated by the people who care.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company