On Thu, Jun 28, 2018 at 8:21 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Good point. I have never used it but I can see its value. I have added
> it to my template.
FWIW, I developed a document on committing for my own reference, with
some help from Andres. A lot of it is about commit message style, the
use of fields, and so on. But I've also developed a check list for
committing, knowing that there are a few classic mistakes that
committers will make from time to time despite knowing better. These
are worth checking against mechanically, IMV. Here are some actual
examples from this document that I refer to:
* Double-check release build compiler warnings.
* make check-world.
* When adding tests files, make sure that they're added to both serial
and parallel schedules.
* When adding a new GUC, postgresql.conf.sample needs to be updated, too.
* Consider the need for a catversion bump.
* Don't assume that you haven't broken the doc build if you make even
a trivial doc change. Removing a GUC can break instances in the
release notes where they're referenced. Even grep can miss this, since
references to the GUC will have dashes rather than underscores, plus
possibly other variations.
* Do a dry run before really pushing by using --dry-run.
Of course, you ought to know that you should do this stuff anyway, but
in the real world many mistakes happen when a step is skipped over
during a routine process, perhaps caused by a seemingly insignificant
last minute change. The points are organized in a way that makes a run
down quick and easy, even when committing a trivial patch.
--
Peter Geoghegan
