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 02:23 +0300, Dmitry Gutov wrote:
> 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.

Sure, all you say sounds reasonable. The point I'm trying to make is that you
have to ask the author for better commit message either way. IOW, you have to
ask that disregarding whether they're obliged to write down the list of
functions changed or not. So having the list didn't help here.

Admittedly, I might be the wrong person to make up an example since I didn't see
the point in this list to begin with. Better examples are certainly welcome.

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

Please note we're discussing whether having the list of functions changed is
worth it comparing to just the commit message. Having a good commit message is
just as enough, so you "won't have to spend as much time doing it". Like, in the
example with factoring out a code from 34 functions it's enough to just write
"Many functions use same code pattern to do X. Factor it out to a separate
function Y". What changes if instead of this one sentence you have 34 lines with
function names? Besides, as I hopefully showed in my prev. paragraph, if an
author is bad in writing commit messages, having that would hardly change
anything.