Re: Deriving release notes from git commit messages

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deriving release notes from git commit messages
Date: 2011-06-24 20:52:45
Message-ID: 201106242052.p5OKqj319301@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Fri, Jun 24, 2011 at 2:47 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> > On 06/24/2011 01:42 PM, Robert Haas wrote:
> >> 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 don't see any good way to extract the list of commits relevant to the
> > release notes without something like it. ?Right now, you can't just mine
> > every commit into the release notes without getting more noise than signal.
> > ?Something that tags the ones that are adding new features or other notable
> > updates, as opposed to bug fixes, doc updates, etc., would allow that
> > separation.
>
> Oh, I see. There's definitely some fuzziness about which commits make
> it into the release notes right now and which do not - sometimes
> things get missed, or sometimes Bruce omits something I would have
> included or includes something I would have omitted. OTOH, it's not
> clear that making every committer do that on every commit is going to
> be better than having one person go through the log and decide
> everything all at once.
>
> If I were attacking this problem, I'd be inclined to make a web
> application that lists all the commits in a format roughly similar to
> the git API, and then lets you tag each commit with tags from some
> list (feature, bug-fix, revert, repair-of-previous-commit, etc.).
> Some of the tagging (e.g. docs-only) could probably even be done
> automatically. Then somebody could go through once a month and update
> all the tags. I'd be more more willing to volunteer to do that than I
> would be to trying to get the right metadata tag in every commit...

That tagging is basically what I do on my first pass through the release
notes. For the gory details:

http://momjian.us/main/blogs/pgblog/2009.html#March_25_2009

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-24 21:08:30 Re: ALTER TABLE lock strength reduction patch is unsafe
Previous Message Bruce Momjian 2011-06-24 20:34:33 Re: pg_upgrade defaulting to port 25432