Re: Deriving release notes from git commit messages

Greg Smith wrote:
> 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.

We could have the items put into release note categories and have a
button that marks incompatibilties.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +