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 Sun, 2020-06-21 at 00:31 +0300, Konstantin Kharlamov wrote:
> 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|hu
> > > aw
> > > ei|c
> > > odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|
> > > mi
> > > cros
> > > oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcproj
> > > ec
> > > 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.

Btw, I figured I botched my calculations by using last 500 commits. If in one
project a few persons posted huge patchsets, but in another nobody, then clearly
the latter gets more mails in last 500 commits, which is wrong.

So, I recalculated by looking at date of the last commit of those "500" in GCC,
and used that date on Clang. I made sure to sort out other corporate mails too.
Command I used is:

        git log --since="Jun 8 21:34:46" --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|imagelabs|xilinx|sap|sas|sigmatechnology|sonarsource|ericsson|lowrisc|hight
ec-rt|polymagelabs)\.(org|com|de|cz|cn|ai|se)" | sort -u | wc -l

So, now GCC still gets 15, while for Clang this number gets increased to 89.