Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: eliz@gnu.org, arne_bab@web.de, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 01:39:17 +0300
> 
> No. I measured specifically for you: "Sending Patches" alone is 5884 
> characters
> not counting bullets, and my email was 3491 characters.

When someone posts a patch, he or she is not requested to read that
section, let alone pass some kind of exam on being familiar with it.
I'm quite sure 99% of contributors don't even know that section exists
in the manual, and have never read it.  So the size of that node is
utterly irrelevant to how hard it is to contribute to Emacs.

If you are keen on studying how this is done and whether and how it
can be improved (as opposed to reiterating that "Cartage shall be
destroyed"), I invite you to read the typical discussions of such
submissions on our issue tracker.  There, you will see what we
_really_ require from the contributors and how the process goes.
Here's one recent example:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64126

Here's another:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64045

And one more:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63913

Yes, many other projects do it differently.  By and large, they are
toy projects whose median life time is about 1/10th that of Emacs, and
the size is accordingly small.  These quantitative differences call
for qualitatively different procedures.  Look at other large projects,
like GCC and GDB, and you will see very similar procedures.  As a
matter of fact, GDB even tried several times to move to PR-like
patch-review workflow based on several available frameworks, and each
time went back, concluding that those frameworks are lacking some
important features.  So the issue is not as clear-cut and simple as
you seem to present it, and the Emacs maintainers perhaps know what
they are doing when they stick to what we have, and not just out of
obstinance.