Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers

[Konstantin Kharlamov]

On Sun, 2020-06-14 at 01:09 +0300, Dmitry Gutov wrote:
> On 13.06.2020 22:23, Konstantin Kharlamov wrote:
> 
> > FTR, I am all for having good commit messages. It is IMO a must have for any
> > git
> > project. But having a list of function names with description for each does
> > not
> > make one. Instead it should be an overview of what is done, why, and how.
> 
> Having a standard that increases the likelihood of having such a 
> description in the commit message without having to ask the contributor 
> twice is not a bad thing.

I agree, it is always great to formalize things. Okay, let's test it. Imagine a
contributor who are not aware how to write a good commit message, to see how
that guideline would help.

So, they make a non-trivial functional change ("non-trivial" because here we
don't care of trivials like "rename a thing" or "factor out the code". These can
often be described just in the commit title alone), let's say, they replaced a
"list" container in a few functions to a binary tree for whatever reason. Now
we'd like to know why did that happen.

In my case they clearly would not produce anything useful, they'll maybe write
"replace list to a binary tree" and that's it. Why? Who knows.

How will they behave in your case? Well, they'll collect the functions list,
then would scrupulously write an immensely useful information against each one
"Replace list to a binary tree here". You see, it is the same here.

> > Suppose you have a patch that deduplicates the same code pattern across 34
> > functions by factoring it out to a single short function. Do you really need
> > that list? I mean, sure it's a fun fact to know, but you'll have to review
> > diff
> > anyway.
> 
> Yes and no. If I get the purpose of the diff, I could scan the contents 
> more superficially (depending on what kind of changes are proposed, and 
> where).

Sorry if I'm misreading, but given the context of comparing commit-messages with
the list and without, I can only interpret the "yes" as "yes, one sentence that
says the code pattern is factored out from all the functions is not enough, I
need a similar sentence to be repeated 34 times". Is there other interpretation
that I do not see, or do I get it right?

> > If anything, it only burdens you by forcing to check that each function
> > is on the list.
> 
> I usually don't.

This! Strictly speaking, as a reviewer you should check it. If a contributor
forgot to add or remove a function on v2 of patches, and you passed them your
Reviewed-by, wrong commit message would partially be your fault.

You do not usually check it exactly because it is trivially a burden.