Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> FWIW, I'm a bit suspicious of the idea that we need to make the commit
>> messages automated-tool-friendly. What tools are there that would need
>> to extract this info, and would we trust them if they didn't understand
>> "nuances"?
> Well, I think what people are asking for is precisely a fixed format,
> and I do think there is value in that. It's nice to capture the
> nuance, but the nuance is going to get flattened out anyway when the
> release notes are created. If we all agree to use a fixed format,
> then a bunch of work there that probably has to be done manually can
> be automated.
I'm not particularly impressed by this argument --- as someone who
regularly prepares release notes, I see exactly zero value in this
to me. I'm willing to go along with it if there's consensus, but the
argument that "Foo: Bar" format has more value than free-form hasn't
actually been made in any form that withstands any skepticism.
In any case, agreeing on a set of "Foo:" keywords isn't nearly enough
to allow any useful automated processing. You have to standardize
the "Bar" part as well, and that hasn't been addressed at all.
Some example questions:
In "Bug:", bug number with or without "#"? What format to use if
there's more than one related bug?
In headers referring to people: name? email? both? what if we have
incomplete information (not unusual in bug reports)? what about
referencing multiple people in same header? what can we do to avoid
variant spellings in different commit messages?
In "Backpatch-through:", how are we to indicate version numbers
exactly? what about special cases such as a patch applied
only to older branches? And perhaps most importantly, why are
we bothering with that at all when git can tell us that much
more reliably? (Personally, I only bother with mentioning this
in the commit message to the extent that I'm explaining *why*
I patched back so far and no further. Which I think is useful
information that a "backpatch-through: N.N" kind of entry would
entirely fail to capture.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
