Re: Template for commit messages - Mailing list pgsql-hackers

On 28 January 2016 15:57:15 CET, Robert Haas <robertmhaas@gmail.com> wrote:
>On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra
>>> <tomas.vondra@2ndquadrant.com> wrote:
>>>> Why can't we do both? That is, have a free-form text with the
>nuances, and
>>>> then Reviewed-By listing the main reviewers? The first one is for
>humans,
>>>> the other one for automated tools.
>>
>>> I'm not objecting to or endorsing any specific proposal, just asking
>>> what we want to do about this.  I think the trick if we do it that
>way
>>> will be to avoid having it seem like too much duplication, but there
>>> may be a way to manage that.
>>
>> 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"?
>>
>> I'm on board with Bruce's template as being a checklist of points to
>be
>> sure to cover when composing a commit message.  I'm not sure we need
>> fixed-format rules.
>
>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.  However, if we all agree to use a fixed format except
>for you, we might as well just forget the whole thing, because the
>percentage of commits that are done by you is quite high.

Before I agree to adding fixed format lines to my commits, I'd like to know exactly what people would want to do with
theinformation. "Bunch of work that probably could be automated" doesn't cut it. For example, if I tag someone as
"Reviewed-by",does it mean that his name will automatically appear in the release notes? Or if there's a bug, is the
reviewerthen somehow responsible for missing it?
 

As a way of saying "thank you", I like a personalised, nuanced, message much better. True, we can do both. A good thing
aboutprocessing the commit messages manually e.g  for compiling release notes is that there's human judgement on what
toinclude.  Of course, that's a lot of work. Which is why I'd like to hear from whoever wants to make use of these
linesto explain in more detail what information they need,  and what they would do with it, to make sure that what we
addis actually useful, and that we don't add noise to the commit messages unnecessarily.
 

- Heikki