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 <hi-angel@yandex.ru>]

On Fri, 2020-06-19 at 14:48 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: Eli Zaretskii <eliz@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>, Stefan
> > 	Kangas <stefan@marxist.se>, emacs-devel@gnu.org
> > Date: Fri, 19 Jun 2020 01:34:21 +0300
> >
> > > I’d also like to note that this list can be invaluable when rebasing
> > > commits and resolving conflicts.  It’s not strictly necessary (just like
> > > other parts of a version control workflow are not strictly necessary),
> > > but it can serve as a sanity check in a time when the diff is not
> > > authoritative as it is in flux.
> >
> > While it may be useful, but explicit examples may be more interesting. Right
> > now
> > when I read your text about this list in the context of resolving rebase
> > conflicts, I only see the downside that if the conflict came up because a
> > function was renamed, you need to go fix the commit message too.
> >
> > Even worse: if upon rebasing a function was renamed, you may not get any
> > conflicts (i.e. because thunk you modified didn't include the beginning of
> > the
> > function), and now your commit message is broken without you even noticing.
>
> There's no requirement to retroactively fix commit log messages when
> files or functions are renamed.  The renaming is recorded in the
> history and can be found when one needs to explore the history of some
> code fragment.
>
> What is important is that the log message names the files and
> functions/macros/data structures as they are called at the time of the
> commit, because the log message is many times read in conjunction with
> the diffs.
>
> So I don't think the difficulties you describe are real.

Are you saying that wrong commit messages are okay? Will it be okay if I make a
v1 of a patch where just one function is changed, and then in v2 I additionally
modify a dozen of others, and won't add their names to the commit message?

Also, what you say here contradicts to your quote of GNU standard, which says
the list is needed to generate Changelog files. Because not fixing commit
messages retroactively will result in wrong Changelogs.

What's the point in wrong Changelog files and wrong commit messages?

> > Let me sum up the positive mentions: so far, you just say it simplifies
> > review
> > for you, but I don't know your workflow, there may be many factors that make
> > you
> > assert that, which does not necessarily applies to everyone. Dmitry said the
> > list makes better commit messages from novices, but again when I tried to
> > dig
> > deeper, that discussion died.
>
> When you contribute changes to a project, you need to satisfy the
> workflows of others, even if they differ from yours.  So you need to
> respect the opinions of the project developers when they tell you this
> information is of help to them.

Right. Judging by the fact you say this me, I have a feeling you miss the point
why we're even discussing this.

Let me abstract from Emacs a bit. People like different things, which is okay,
everyone has unique life and character. And some like things that would in fact
hurt when applied to others! That's okay too, just don't apply these to
everybody. There're communities for them as well, so it's not like they're
alone.

Now let's get back to Emacs. I hope it's unquestionable that purpose of Emacs
project is prosperity of Emacs project. It doesn't have explicit purpose to
cater to Emacs contributors or developers. But if you ask "how can we make Emacs
evolve and prosper", the "making Emacs contributors, developers and users
comfortable" is hopefully an obvious answer.

Having good developer practices is an implication of "making
developers/contributors comfortable". Which includes, that if some developer
practice (I'm pointing out here to the functions list) 1. carries burden on
everyone, and 2. Makes happy only a few (perhaps, because of their habits or
whatever), we should ditch this practice.

Because Emacs project is not a community of peoples who like a specific thing
that would hurt others when applied to them. Instead it's a community who want
Emacs to evolve and prosper.

> Here are the excerpts from the latest GNU Coding Standards manual I
> mentioned above:
> […snipped…]

Thanks. I should say, it's a big text, half of which basically says "it's cool
to have" which doesn't answer the question "why". So, I'm sorry if I missed some
point while reading this, in this case pointing this out more explicitly might
help.

Regarding the discussion I grasped from it two points:

1. The list is used to generate Changelogs.
2. The standard does not enforce having the list in commit messages if you're
using a decent VCS (which I'd think includes git)

The text then goes into details that generating Changelogs from a VCS alone may
be unreliable. The example it shows can be reproduced on Emacs repo as follows:
if you do `git log -1 -p 50a0126402d`, you'll see some renames, however the
context above the hunk shows not the variable/function being renamed.

I'd argue it would be way more productive to make git produce what Changelog
files need correctly rather than forcing tedious manual work upon everybody. git
already can recognize the context correctly, we just need a specific flag to
only make it show changed functions/variables (ATM it seems not to have it, at
least I didn't find one).