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

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: rekado@elephly.net, joaotavora@gmail.com, dgutov@yandex.ru,
>  stefan@marxist.se,  emacs-devel@gnu.org
> Date: Sat, 20 Jun 2020 18:41:37 +0300
> 
> > Also, let's face it: changesets where v2 renames many symbols present
> > in v1's log are rare.  There's no need to make these rare cases sound
> > as if they were the rule: they are not.
> 
> Please note that I haven't provided example here. From your text you seem to
> think I implied scenario where v1 is an RFC, and later patches are actual
> changes.

Many times the first version of a patch is an implicit RFC, especially
for a rare contributor who cannot be sure his or her ideas will be
accepted by the developers.

As another data point, I frequently post my proposed patches without
log messages, because I believe people generally trust me to produce
the right log messages when the time comes.

> It's not what I had in mind. I rather was thinking about making some change in
> v1, and then as result of code review making more similar changes to other
> places. As a real life example, while discussing the patch `Replace manually
> crafted hex regexes with [[:xdigit:]]`, more places where similar changes can 
> be
> applied were uncovered.
> 
> In code-refactoring I think it's pretty common to happen. You can't omit the
> list in v1 in these cases because you don't know there will be followups.

Fair enough, but massive renames are still rare, IME, and thus the
danger of having to completely rewrite the log messages is also small.

> Sounds reasonable. I'd like to see those discussions though to understand the
> background, and maybe even participate in them. Do you have any reference?

They are scattered across different mailing lists (and across many
months), but you can find many of them on bug-standard@gnu.org and on
gnu-prog-discuss@gnu.org.

> My point is the functions list is not necessary for having good
> commit messages.

Our experiences are different, then.  I find them very important in at
least some cases.

> This whole thread is dedicated to "why having the list is necessary as opposed
> to not having it", and while text explains "why having the list is good" in
> general, but it does not make comparison to not using it. There's no answer to
> that question.

Isn't saying "A is good to have" the same as saying "not having A is
not so good"?

> Again, I don't see why just saying in commit message e.g. "Factor out code 
> doing
> X out of all functions", is worse than additionally making the list of those
> functions (or is it a bad example, and you have a better one in mind? Great, I
> want to hear it!).

For repetitive mechanical changes, it might be okay.  There's no
argument that some changes don't need detailed lists.  The argument is
whether having them in general is helpful.  If you are saying that in
some cases they are redundant, then we agree at least in principle
(though we could disagree in specific cases).  But if you are saying
they are seldom or never needed or useful, then I disagree, based on
my experience.

> > I encourage you to talk to Git developers so that they improve this
> > capability.  Not sure this is going to happen in practice (knowing how
> > the diffs are generated, and given that one GNU project using Git
> > after another sets up alternative tools for overcoming these
> > problems), but it definitely cannot harm, so by all means go for it.
> 
> I might do it, but I need motivation. If I knew this is the only reason Emacs
> has requirement for the functions list, thus having such ability in git would
> allow to drop this requirement, I'd do it. Right now people seem to prefer to
> stick to having the list for other reasons (which are being discussed in the
> text above), so clearly even if git got such ability, it would be of little 
> use
> to Emacs.

It depends how good a job they do.  If they do a perfect job, which
will allow generating accurate ChangeLog-formatted entries without
providing the lists of functions in the log messages, then we might
indeed drop the requirement.