Re: Deriving release notes from git commit messages

[ I'm a bit late to the party on this thread, but anyway: ]

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jun 24, 2011 at 7:51 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> On 06/24/2011 03:28 PM, Christopher Browne wrote:
>>> I expect that the correlation between commit and [various parties] is
>>> something that will need to take place outside git.

>> Agreed on everything except the "Author" information that is already being
>> placed into each commit. The right data is already going into there, all it
>> would take is some small amount of tagging to make it easier to extract
>> programatically.

> Yeah, I think we should seriously consider doing something about that.

My recollection is that we considered and rejected using git's Author:
field, primarily because it doesn't scale to multiple authors. We might
be more accustomed to git now than we were last year, but it still won't
scale.

I wouldn't have a problem with establishing a convention that we
write credits in commit messages in a more standardized way, ie put
something like "Author: Joe Blow <joe(at)blow(dot)nom>" in the body of the
commit message. However, the points that were raised about commit
messages being effectively uncorrectable after-the-fact seem to me
to put a big crimp in the idea of using that as the primary source
of credit information. We'd still need something like the web app
Robert described in <BANLkTimOxDA08qM4LSH4QjA3YZtyuuewsA(at)mail(dot)gmail(dot)com>
to allow correction of the info.

There's a point I didn't see raised with respect to Greg's main original
idea, that the commit message should contain text that could be used
directly in the release notes. Namely, that the commit messages are
written for a different audience than the release notes are, and so it
is perfectly natural for them to need considerable massaging to create
release notes. Whoever is doing the release notes also has to exert
a good deal of editorial judgement to phrase all the notes in similar
voices, allot an appropriate amount of space to each depending on the
user-visible impact, etc. That work would still have to be done even
if each committer always attempted to provide release-note-ready text.
So I'm not sure that much work would get saved this way.

regards, tom lane