Re: contributing to Emacs

[Konstantin Kharlamov <hi-angel@yandex.ru>]

On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
> > 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.

You can't send a patch if you don't know how and where to send it 😊 So you
can't avoid reading that section.

> 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

I looked through these links but I'm not sure what they supposed to show me.
I've been contributing patches from time to time and back when I had my first
ones I've been multiple times pointed to CONTRIBUTE file due to getting either
formatting or something else wrong. Which is why I'm saying there's an
expectation to read that file as well.

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

Mesa isn't small. Neither is systemd, docker, podman. These are very active
projects and they are in very active use today. If you go up the stack: Gnome,
KDE, they also are big active projects in use, and they use workflow similar to
Mesa and systemd. There's also WINE as another example.

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

I didn't know. Do you have a link at hand? I'd be curious to read what was the
problem. Apparently there wasn't an article on Phoronix about it, kind of sad.

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