From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Template for commit messages |
Date: | 2016-01-28 12:57:59 |
Message-ID: | CA+TgmoZ3cU=2_NSVsHKB1J2ws4EozC4tox8G83bkxcqzSuKLBA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 28, 2016 at 3:52 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> There has been a request in the FOSDEM developers meeting that
> committers use a more consistent format for commit messages. This is
> the format I use:
>
> -- email subject limit -----------------------------------------
> -- gitweb summary limit --------------------------
>
>
> Report by
>
> Patch by
>
> Reviewed by
>
> Backpatch through
>
> The dashed lines are used to specify a target length for the summary
> line and are automatically removed before the commit message is posted.
One of the things I like about the current free-form approach is that
you can indicate nuances, like:
Person X reviewed an earlier version of this patch that was a lot
different than this one.
Person X reviewed this patch but didn't totally endorse it.
Person X wrote the documentation for the patch, but none of the code.
Person X wrote the vast bulk of this patch, even though there are some
other authors.
Should I just abandon the idea of trying to capture those details, or
does this format contemplate a way to include them?
(Also an important question: Has Tom agreed to use this new format?
Because I think that anything the rest of agree on that he's not
prepared to endorse is not going to have much value.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-01-28 13:01:03 | Re: Request - repeat value of \pset title during \watch interations |
Previous Message | Etsuro Fujita | 2016-01-28 12:55:33 | Re: Minor code improvements to create_foreignscan_plan/ExecInitForeignScan |