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 Thu, 2020-04-23 at 19:07 +0200, Stefan Kangas wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> The reasons why package authors would not want to include it, on the
> other hand,
> could obviously vary.  Some of the reasons I have seen are
> unfortunately very shallow:
>
> - Misconceptions about how hard it is to work with emacs-devel.

Hello! As someone who does not contribute to Emacs for the sole reason
it is *way* harder than in any other project I'm aware of (although
well in line with other GNU projects, but even among them Emacs takes
the lead) I want to emphasize this is not a "shallow reason".

It all comes down to Emacs development not being automated. Which puts
down too much strain on contributors (not mentioning Emacs maintainers
here, because last time this discussion happened (1.5 year ago I
think), Eli ensured me that they are okay. Fair enough: I'm not a Emacs
maintainer, not gonna speak for them).

1. There are many wrong ways to send a patch; and the correct one is
the most non-obvious. Most popular mistakes I think come down to copy-
pasting the patch into email client. Most modern email clients require
lots of tinkering before they work fine with plain text, otherwise
they'll screw patch up in various ways (breaking lines, replacing
whitespace, removing whitespace, you name it).
   Okay, so usually email-based projects recommend using git-send-
email. Recently I sent a patch like this¹ and got a complaint it
doesn't look like what git-format-patch would produce (is that maybe a
hint maintainers are being strained too?). Huh, wrong way again? I'll
give you some examples so you'd see the format looks exactly what other
email-based project use/used: one from Mesa project² (well, before they
moved over to Gitlab-based development) and another one from kernel³.
   What's the correct way? Well, apparently it is either to combine in
some way git-send-email and git-format-patch, or it is to attach a
patch to email. "To attach", who would've thought? Attaching patches
is frowned upon in all other email-based projects because it is hard
to review it, Idk why Emacs even allows that…
   Okay, let's get back to all those "great packages not included in
Emacs": YOU CAN NOT SEND THEM PATCH WRONG. Sorry for caps, I want to
make sure it is visible: there is no way I'll send a patch, say, to
company-mode, and will get a reply "Dude, your patch does not apply
here"! They use either (open-source btw) Gitlab or (proprietary)
Github. You can use command line or web-browser to send patches —
either way, it all becomes a thing called merge/pull request, and
making sure it is correct is all automated. Zero efforts from package
maintainers or contributors.

2. Unusual requirements from commit messages: no other projects require
writing down a list of functions I changed just for the fun of it. This
is what there diff is for! Let me guess where the requirement came
from: I remember seeing that Emacs maintainers accept even patches
with a bunch of unrelated changes, like 1.
renaming a variable, 2. refactoring a code, 3. adding a new feature. No
serious project would accept such patches, but apparently Emacs decided
to hack that around, and are instead requiring that people write
down each function name and its change in commit message.
   Okay, you want this — but could you at least automate it!
And no, some Emacs function does not cut it, people not necessarily use
git from Emacs. I
personally don't. Please, use git hoooks, because this is what everyone
is *forced* to use, you can't possibly miss a git hook. And please,
make sure that when people do git-commit-amend, the function names are
updated accordingly.
   Full automation, to make sure this unusual unique requirement of
Emacs development stays as unobtrusive as possible.

3. FSF assignment: yeah, it is easy to get. But as a package
maintainer, would I want more contributions or only having code from
elite members of FSF? I'd go for the former. If some package user found
some corner case in a function in my package and wants to contribute it
now, and I stop them "go assign some copyright and don't appear at my
project without that", this is a punch into motivation. They may do it
or not, it depends.

4. Patches are discussed on a bugtracker. Good news: contributors
probably won't care. Bad news: as a package maintainer I'd not want to
give up my abilities to 1. Close outdated discussions 2. See the diff
between current and previous patchset version 3. Immediately see which
patchset is the current version. 4. Automatically run CI on the new
uploaded version of the patchset. 5. Immediately merge the patchset
once I'm fine with the changes.

5. As a contributor, when I stumble upon a bug I could fix in
software, first thing I usually do is go check it is not fixed in
latest code and that there's no pending merge/pull requests that seem
to fix that same thing. So, for example, I want to see pending
patchsets to python-mode, can I do that with Emacs
"bug-patch-tracker"? No, with debbugs.gnu.org you can either find
pending patchsets, or you can make a text search, but over everything:
bugs, patchsets, closed or not…

P.S.: I have a feeling, people on Emacs-devel don't consider these to
be anything but nuance. Well, I've got FSF assignment for contributing
to Emacs, and since then I have many times stumbled upon things I
could try to improve. But every time it happens, I remember how hard
it is to contribute here, and dismiss myself with "no, not worth
it". The patch from two weeks ago¹ was the exception just because when
I stumbled upon that problem, I immediately figured it is likely a
one-liner fix.

As it currently stands, I'd strongly recommend against moving packages
from gitlab/github to Emacs upstream.

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41684
2:
https://lists.freedesktop.org/archives/mesa-dev/2018-December/210803.html
3: https://lists.gt.net/linux/kernel/3588040