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

[Dmitry Gutov]

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.

> 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).

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

I usually don't.

> Commit message should reveal the intention of the changes (and
> perhaps, if OP thinks changes may raise questions, they should also write the
> reasoning).

That, too.

In any case, ChangeLog-style commit messages *are* a barrier for 
contributing, and one could argue that in the end they don't bring 
enough benefit to offset that.

But our experience shows that they do bring a certain benefit.

> On that matter I often love to quote a post from 2009 by Peter Hutterer, a
> libinput and Linux HID subsystem maintainer. A post that is old but is not
> outdated http://who-t.blogspot.com/2009/12/on-commit-messages.html

It's a pretty good guideline. But one that's a bit harder to check and 
enforce.