Re: [CORE] postpone next week's release

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, pgsql-core <pgsql-core(at)postgresql(dot)org>
Subject: Re: [CORE] postpone next week's release
Date: 2015-06-01 16:56:20
Message-ID: 26465.1433177780@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2015-06-01 12:32:21 -0400, Tom Lane wrote:
>> There are good reasons to write the release notes all in one batch:
>> otherwise you don't get any uniformity of editorial style.

> I agree that that's a good reason for major releases, I do however
> wonder if it'd not be a good idea to do differently for backpatched
> bugfixes. It's imo a good thing to force committers to write a release
> notice at the same time they're backpatching. The memory is fresh, and
> the commit message is more likely to contain pertinent details.

We do expect committers to write commit log messages that contain
appropriate raw material for the release notes. That's not the same
as expecting them to prepare an actual, sgml-marked-up, release note
entry that's in good English and occupies a reasonable amount of space
relative to other items.

Jim's point about merge problems is very pertinent as well. In the
first place, if we had running release notes like that, they'd often
differ from one branch to the next, making back-patching rather annoying.
In the second place, SGML is so bulky that the patch context you'd be
working with would frequently look like not much more than

</para>
</listitem>

<listitem>
<para>

making it very easy for the hunks to be misapplied.

Lastly, we have recently adopted a practice of labeling release note
entries with the associated commit hashes. I dunno how much value that
really has, but it would be entirely impossible to write such labels
in advance of pushing the fixes.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-06-01 17:41:02 Re: [NOVICE] psql readline Tab insert tab
Previous Message Andres Freund 2015-06-01 16:34:43 Re: [CORE] postpone next week's release