Re: Deriving release notes from git commit messages

On Fri, Jun 24, 2011 at 2:47 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> On 06/24/2011 01:42 PM, Robert Haas wrote:
>> I am disinclined to add a "feature"
>> annotation.  I think it is unlikely that will end up being any more
>> useful than just extracting either the whole commit message or its
>> first line.
>
> I don't see any good way to extract the list of commits relevant to the
> release notes without something like it.  Right now, you can't just mine
> every commit into the release notes without getting more noise than signal.
>  Something that tags the ones that are adding new features or other notable
> updates, as opposed to bug fixes, doc updates, etc., would allow that
> separation.

Oh, I see. There's definitely some fuzziness about which commits make
it into the release notes right now and which do not - sometimes
things get missed, or sometimes Bruce omits something I would have
included or includes something I would have omitted. OTOH, it's not
clear that making every committer do that on every commit is going to
be better than having one person go through the log and decide
everything all at once.

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 am not inclined to try to track sponsors in the commit message at
>> all.
>
> I was not suggesting that information be part of the commit.  We've worked
> out a reasonable initial process for the people working on sponsored
> features to record that information completely outside of the commit or
> release notes data.  It turns out though that process would be easier to
> drive if it were easier to derive a feature->{commit,author} list
> though--and that would spit out for free with the rest of this.  Improving
> the ability to do sponsor tracking is more of a helpful side-effect of
> something that's useful for other reasons rather than a direct goal.

OK, that makes sense.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company