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 14.06.2020 02:00, Konstantin Kharlamov wrote:

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

We might want to know more things than that, actually.

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

Then I'll probably ask. If the preceding discussion, or the contents of 
the associated bug report, haven't made the reason clear already.

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

Let's imagine that I know that in the codebase 'list' is used in many 
places, and then in the ChangeLog entry I see that only some of them 
have been replaced.

Then I cut the review short and ask about the rest of the places.

Similarly if they actually described the reason the change, but the 
enumerated changes don't match that goal (e.g. some changes in some 
files are missing).

Another concern that can come up are whether they added 
backward-compatibility aliases (to satisfy our backward compatibility 
policy), which should also be apparent from the ChangeLog style entry. Etc.

> 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?

Yes, as in "I'd have to review the diff anyway", and no, as in "I won't 
have to spend as much time doing it as I might have without the 
ChangeLog style summary".

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

I'm all in favor of automated checks. Someone would need to implement 
them, though.