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 21:04:23 +0300
> 
> > 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.

Like I said, latest GCS leave this decision to the project developers'
discretion.

You may also wish to check how long do those projects live, and
compare that with Emacs.  Not every technique that is good for a
5-year project will scale well for a 35-year one.  In my work on Emacs
I quite frequently need to look at changes made 30 years ago, using a
different VCS.

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

I hope you realize how saying that makes your opinions matter much
less, do you?

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

GCC is alive for 33 years, so I think your theory eats dust.  Many of
the GCC and GDB developers get paid for their work, but that doesn't
mean the project is less viable, and the long history of both GCC and
GDB is the proof.

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

That text described the advantages of having the lists precisely so
you could consider your options and make an informed decision.