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 Sat, 2020-06-20 at 21:43 +0300, Eli Zaretskii wrote:
> > 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.

Right, as well as not every technique that was good 35 years ago is still as
good nowadays.

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

No, I don't. Are you implying that voicing bad opinion regarding GNU on a GNU
mailing list may lead to some people to start ignoring me? If so, I'm fine with
it. You see, my opinions are based on facts. My interpretation of them may be
wrong, but if I expressed them, I am not aware of it. On this mailing list, we
carry technical discussions, which means expressing arguments and counter-
arguments based on facts, and being ready to turn out to be wrong.

Ignoring someone based on their opinion instead of trying to prove them wrong is
not a technical behavior. These are not very technical people, they sometimes go
personal, so if their reaction is a silence, that's fine with me.

FYI, for me even participating in discussions is hard, for personal reasons. But
I am a software engineer, and I get the boundary between personal feelings and
technical discussions, so I get over it.

> >     git log -500 --format="%ae" | grep -vP
> > "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huaw
> > ei|c
> > odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|mi
> > cros
> > oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcprojec
> > t|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.

Okay, let me say beforehand that both GCC and Clang are very active projects
right now. Just in case, so there's no misunderstanding.

So, times are changing. In older times there were no standard to development,
Git was not as popular, development practices are varied too. So, as long you
could get your patch to a project, any odd contribution requirements were fine,
they hardly would set a barrier.

But these days Git got over all other VCSes (and for a reason), so using SVN or
Perforce, or whatever, is a barrier to contribution. 12 years ago Github was
founded, and then also the open-source clone Gitlab appeared. These two pretty
much set the standard development model nowadays (for a reason too). There still
are projects that use other models, but this is a barrier to contributors.

What I'm getting at is that your reasoning that since GCC is 33 years old it
will live on does not work. For a project to "live on" it needs to be active.
Sure GCC is active! But its activity mainly stems from paid people and
maintainers. Whereas in Clang a large chunk of it stems from contributors. Let
me repeat, paid people come and go, so do maintainers (they may burn out, or
just move on). These contributors are the ones who will become new maintainers
and the ones who advertise the project in their environment.

I hope it makes clear the future of what project looks brighter.

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

I can't make decision since I am not a Emacs maintainer.