On Thu, Oct 1, 2015 at 10:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2015-10-01 11:07:12 -0400, Tom Lane wrote:
>>> As one of the people who do most of the gruntwork for release notes,
>>> I can tell you that that sort of fixed-format annotation is useless
>>> and usually annoying. I can see what branches you fixed the bug in
>>> anyway, from git_changelog's output.
>
>> I know that I very frequently wish that information were in the commit
>> messages in a easily discernible way.
>
> I'm inclined to think that commit messages are not really the right medium
> for that at all. Commit messages ought to be primarily text for
> consumption by humans. If we had a tracker, I think that it would be the
> place for fixed-format metadata, such as "fixed in version(s) x,y,z" and
> "fixed by commit(s) aaa,bbb,ccc". Expecting the tracker to link to the
> commit rather than vice versa would also solve a bunch of other problems
> like assigned-after-the-fact bug numbers. Not to mention plain old
> mistakes: once committed, a log message is immutable, but a tracker could
> be updated as needed.
>
> If this process actually works, I could see the tracker becoming the
> source material for generating release notes, at least for bug-fix
> notes. We do it off the commit log now because that's all we've got,
> but the log isn't really ideal source material.
At least some of that information could be generated by crawling and
parsing commit emails, I think. The missing link FWICT is reliably
tying the bug resolution to the relevant commit. Maybe we could
teach the tracker to watch for "fixed by commit ABCDEF" in the bug
list (and maybe hackers, too), identifying the commit as a bug fix and
associating it to the release branches. That gets crawled and
rendered to a database for collection and reporting.
merlin