Re: [CORE] postpone next week's release

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jim Nasby <Jim.Nasby@bluetreble.com>
Cc: Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Magnus Hagander <magnus@hagander.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, pgsql-core <pgsql-core@postgresql.org>
Date: 2015-06-01T16:32:21Z
Lists: pgsql-hackers
Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> FWIW, I've always wondered why we don't create an empty next-version 
> release notes as part of stamping a major release and expect patch 
> authors to add to it. I realize that likely creates merge conflicts, but 
> that seems less work than doing it all at the end. (Or maybe each patch 
> just creates a file and the final process is pulling all the files 
> together.)

There are good reasons to write the release notes all in one batch:
otherwise you don't get any uniformity of editorial style.

			regards, tom lane


Commits

  1. Add Valgrind buffer access instrumentation.

  2. Fix wrong merge resolution making pg_receivexlog fail in 9.2.