Skip site navigation (1) Skip section navigation (2)

Re: Deriving release notes from git commit messages

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deriving release notes from git commit messages
Date: 2011-06-25 02:22:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

>> The existing CommitFest data goes quite a long ways towards capturing
>> interesting information (with the likely exception of sponsorship);
>> what it's missing, at this point, is a capture of what commit or
>> commits wound up drawing the proposed patch into the official code
>> base.
> The main problem with driving this from the CommitFest app is that not every
> feature ends up in there.  Committers who commit their own work are one
> source of those.  Commits for bug fixes that end up being notable enough to
> go into the release notes are another.


> I agree it would be nice if every entry marked as "Committed" in the CF app
> included a final link to the message ID of the commit closing it.  But since
> I don't ever see that being the complete data set, I find it hard to justify
> enforcing that work.  And the ability to operate programatically on the
> output from "git log" is a slightly easier path to walk down than extracting
> the same from the CF app, you avoid one pre-processing step:  extracting the
> right entries in the database to get a list of commit IDs.


Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-06-25 02:22:55
Subject: Re: pg_upgrade defaulting to port 25432
Previous:From: Peter GeogheganDate: 2011-06-25 01:41:38
Subject: Re: Latch implementation that wakes on postmaster death on both win32 and Unix

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group