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

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

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-06-25 00:41:11
Subject: Re: Deriving release notes from git commit messages
Previous:From: Peter GeogheganDate: 2011-06-25 00:02:40
Subject: Re: News on Clang

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