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

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 (view raw or flat)
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

pgsql-hackers by date

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

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