Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: ams@gnu.org, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 11:53:09 +0300
> 
> On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
> > 
> > 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.

False.  People know how to reach us even without reading.  The few
Emacs mailing lists are common knowledge, and are just an Internet
search away if someone needs that.

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

How patch submitting process works in reality.

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

There's no such expectation.  We live in the real world, not in some
fantasy.  When the patch doesn't follow our conventions, we either
correct that by hand when installing it or (if the deviations are too
significant) ask the contributor to make those changes and resubmit.

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

I said "by and large".

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

I don't have a link, you will have to search the archives of the GDB
list.