Re: Deriving release notes from git commit messages - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Deriving release notes from git commit messages
Date
Msg-id 4E052B6F.8060800@2ndQuadrant.com
Whole thread Raw
In response to Re: Deriving release notes from git commit messages  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Deriving release notes from git commit messages
List 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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: News on Clang
Next
From: Bruce Momjian
Date:
Subject: Re: Deriving release notes from git commit messages