Re: Deriving release notes from git commit messages

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deriving release notes from git commit messages
Date: 2011-06-25 00:27:27
Message-ID: 4E052B6F.8060800@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/24/2011 03:21 PM, Robert Haas wrote:
> 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...
>

I tend not to think in terms of solutions that involve web applications
because I never build them, but this seems like a useful approach to
consider. Given that the list of tags is pretty static, I could see a
table with a line for each commit, and a series of check boxes in
columns for each tag next to it. Then you just click on each of the
tags that apply to that line.

Once that was done, increasing the amount of smarts that go into
pre-populating which boxes are already filled in could then happen, with
"docs only" being the easiest one to spot. A really smart
implementation here might even eventually make a good guess for "bug
fix" too, based on whether a bunch of similar commits happened to other
branches around the same time. Everyone is getting better lately at
noting the original SHA1 when fixing a mistake too, so being able to
identify "repair" seems likely when that's observed.

This approach would pull the work from being at commit time, but it
would still be easier to do incrementally and to distribute the work
around than what's feasible right now. Release note prep takes critical
project contributors a non-trivial amount of time, this would let anyone
who felt like tagging things for an hour help with the early stages of
that. And it would provide a functional source for the metadata I've
been searching for too, to drive all this derived data about sponsors etc.

Disclaimer: as a person who does none of this work currently, my
suggestions are strictly aimed to inspire those who do in a direction
that might makes things easier for them. I can get the sponsor stuff
I've volunteered to work on finished regardless. I just noticed what
seems like it could be a good optimization over here while I was working
on that.

--
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-25 00:41:11 Re: Deriving release notes from git commit messages
Previous Message Peter Geoghegan 2011-06-25 00:02:40 Re: News on Clang