Re: Deriving release notes from git commit messages

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

On 06/24/2011 04:52 PM, Bruce Momjian wrote:
> 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
>

Excellent summary of the process I was trying to suggest might be
improved; the two most relevant bits:

3 remove insignificant items 2.7k 1 day
4 research and reword items 1k 5 days

Some sort of tagging to identify feature changes should drive down the
time spent on filtering insignificant items. And the person doing the
commit already has the context you are acquiring later as "research"
here. Would suggesting they try to write a short description at commit
time drive it and the "reword" phase time down significantly? Can't say
for sure, but I wanted to throw the idea out for
consideration--particularly since solving it well ends up making some of
this other derived data people would like to see a lot easier to
generate too.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-06-24 23:47:23 Re: pg_upgrade defaulting to port 25432
Previous Message Peter Eisentraut 2011-06-24 23:27:55 Re: News on Clang