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 Sat, 2020-06-20 at 19:10 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > 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.

Thanks, I'll look at it.

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

Right. I should mention though, my experience is not specific to myself. Most
non-GNU projects (actually, all I have seen) don't require having the list, but
do require good commit messages. Peter Hutterer, a libinput and kernel HID
subsystem maintainer wrote a good blog-post in 2009 on commit messages, and this
too did not include having the list 
http://who-t.blogspot.com/2009/12/on-commit-messages.html

I also don't think GNU projects are any good to make examples of. This is my
general experience of seeing how new projects get under GNU umbrella to get
never heard of (which I attribute to points listed in my starting mail, since
most of them are unspecific to Emacs).

But to support this claim regarding GNU, I just did some experiment. I
downloaded git repositories of GNU GCC and Clang, and tried to count
contributors to last 500 commits. I was interested in seeing the number of
occasional contributors. I think that if a project only lives by means of
maintainers and paid people, the project pretty much goes down. Maintainers may
burn out, paid people will move on. Number of occasional contributors shows how
big interest in supporting the development, and they're the ones who at some
point may become maintainers too.

So, I looked at "author email" fields and removed ones with email addresses that
are either clearly corporate or clearly maintainers. Not the most scientific
method, I might have missed a few ones who contributed from their personal
email, but I don't expect the difference to be statistically significant.

So, the command is (I hope my email client won't break it terribly):

    git log -500 --format="%ae" | grep -vP
"@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huawei|c
odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|micros
oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcproject|si
five)\.(org|com|de|cz|cn)" | sort -u | wc -l

Results are:
* GCC as of commit 445d8da5fbd: 15
* Clang as of commit 7b201bfcac2: 49

This is some pretty big difference! If I expand the commits range, the
difference increases further.

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

It depends. If A is free, then sure. But if I gotta pay for A, then I'd consider
my options.

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

Okay, I'll ask about it.