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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers