Re: contributing to Emacs

[Konstantin Kharlamov]

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

Okay, let's conduct an experiment. Suppose I am a new contributor who never
contributed via MLs. So first I search for "Emacs contribute". I get this URL
https://www.gnu.org/software/emacs/manual/html_node/emacs/Contributing.html
There I see a suggestion to implement a new feature and submit a patch. So then
I use page search for word "patch" to see where are details on how to do that. I
find a link "Sending Patches". There I find a suggestion to send it to
bugtracker, and then various points about MIME types, what needs to be done,
etc.

In what case do you imagine such new developer would not need to read that
section and still will successfully send a patch? 🤷‍♂️

> > > 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 know how it works, I've been contributing to Emacs. Which is why I'm not sure
what was I supposed to see there. I looked at the links and it seems to be
pretty usual.

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

Okay, maybe something changed. I am saying from my experience of contributing
patches.

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

Well, in this case I might be missing what you meant to say. You pointed out
there are small projects with different workflow, I pointed out there are large
ones. So I guess that cancels out. If that was meant to present some point to
me, I'm not seeing it.