Re: Release note bloat is getting out of hand

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Marko Tiikkaja <marko(at)joh(dot)to>, David Fetter <david(at)fetter(dot)org>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Release note bloat is getting out of hand
Date: 2015-02-03 16:15:15
Message-ID: 4400.1422980115@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 2/3/15 10:11 AM, Marko Tiikkaja wrote:
>> And now that we're on the subject of ponies, it would be nice if the
>> relevant git hashes were included as well.

> That's probably not going to happen. A release-note entry is often the
> combination of many commits, and accurately tracking those is a lot of work.

Well, actually, modern release note entries tend to look like

<!--
Author: Andres Freund <andres(at)anarazel(dot)de>
Branch: master [3fabed070] 2015-01-07 00:19:37 +0100
Branch: REL9_4_STABLE [7da102154] 2015-01-07 00:24:58 +0100
Author: Andres Freund <andres(at)anarazel(dot)de>
Branch: master [31912d01d] 2015-01-07 00:18:00 +0100
Branch: REL9_4_STABLE [84911ff51] 2015-01-07 00:24:47 +0100
-->

<listitem>
<para>
Assorted fixes for logical decoding (Andres Freund)
</para>
</listitem>

because they're prepared on the basis of src/tools/git_changelog output
and so having the git hashes is merely a matter of not deleting that
info after we're done writing the user-visible text. So I could imagine
some tool that presents that info. I'm not volunteering to write it
though ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-02-03 16:20:24 Re: Release note bloat is getting out of hand
Previous Message Tom Lane 2015-02-03 16:10:26 Re: Add LINE: hint when schemaname.typename is a non-existent schema