Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 12:54 +0200, Dr. Arne Babenhauserheide wrote:
> 
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > On Sun, 2023-06-18 at 13:22 +0300, Eli Zaretskii wrote:
> > > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com,
> > > > emacs-devel@gnu.org
> > > > Date: Sun, 18 Jun 2023 13:13:23 +0300
> > > > 
> > > > On Sun, 2023-06-18 at 13:02 +0300, Eli Zaretskii wrote:
> > > > > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > > > > Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org,
> > > > > > luangruo@yahoo.com, 
> > > > > >         emacs-devel@gnu.org
> > > > > > Date: Sun, 18 Jun 2023 12:56:33 +0300
> > > > > > 
> > > > > > Okay, so, here's an obvious one: a patch series sent to
> > > > > > bug-gnu-emacs@gnu.org
> > > > > > should not create separate bugreports for every patch.
> > > > > > 
> > > > > > In ML-managed projects it is typical to send patches as a series,
> > > > > > and
> > > > > > when
> > > > > > you
> > > > > > doing that results in such surprising behaviour, it creates an
> > > > > > additional
> > > > > > emotional and mental load both for you and for maintainers who would
> > > > > > need to
> > > > > > do
> > > > > > something with these separate reports.
> > > > > 
> > > > > Our preference is to send patches as a single patch, not as patch
> > > > > series.
> > > > > 
> > > > > That said, people are sometimes sending series, and we don't ask them
> > > > > to resend, we process those series anyway.
> > > > > 
> > > > > As for separate bug reports, this is easily fixed by merging them.
> > > > 
> > > > Unfortunately merging bugreports does not fix that. The last patch I had
> > > > to
> > > > Emacs was sent with a cover letter and resulted in two reports: one for
> > > > the
> > > > cover letter and another for the patch itself. You may remember that it
> > > > resulted
> > > > in a confusion, because α) discussions happened on both threads, but
> > > > then a
> > > > new
> > > > patch version was only sent to one of them, so there other thread wasn't
> > > > notified that comments were addressed, and β) you may remember 3 months
> > > > after
> > > > the patch got accepted someone was asking the status. Which is because
> > > > one
> > > > of
> > > > the threads was closed saying that the patch is applied, but then the
> > > > other
> > > > thread into which a person was looking has no such comment.
> > > > 
> > > > > So I see no problem here.
> > > > 
> > > > This is psychology. Having a report per patch may not be a problem for
> > > > you,
> > > > but
> > > > when a contributor sends patches and gets into such situation, they do
> > > > not
> > > > know
> > > > it is okay. They will be frightened and frustrated, because it looks
> > > > like
> > > > something just went wrong. Such situation being okay needs at least be
> > > > mentioned
> > > > in "sending patches" section, and at best it should just work.
> > > 
> > > Like I said: we prefer a single patch for each changeset.  The
> > > problems presented by patch series are one reason.  And yet, we will
> > > never reject a patch series, even though it makes the process
> > > inconvenient and confusing.
> > > 
> > > I don't see what else do we need to argued about here.
> > 
> > Well, you see, the "sending patches" section has no mention that a series is
> > unwelcome. And Emacs is the unique project where a squashed patch with many
> > commits is preferred over a series.
> 
> There is "When you have all these pieces, bundle them up in a mail
> message and send it to the developers."¹ which to me implies to send a
> single email.
> 
> But it can easily get missed in the long text (datapoint for that: you
> missed it), that’s why I think the text shown to new contributors should
> get changed.

Well… yes, I did miss it. I see suggestions to have a change per patch (which
implies a series), but this sentence… Even now that I know the meaning, it reads
differently for me due to the context around it. It is not about the amount of
text on the page.

Well. Basically, the problem here is that this sentence just drowns among the
talk about sending "multiple patches" (e.g. 2nd paragraphs starts with "Every
patch…") and me knowing that in ML-managed projects you always send a series.

I also don't think there's a built-in way to send a series as a single message
via `git-send-email`. At least ChatGPT says there isn't, though I didn't exactly
study the man page to see if that's correct. And if a person has experience with
other ML-managed projects, they will likely send patches via `git-send-email`.

I think this phrase needs to be a separate point at the beginning, to emphasise
its significance.

But then, if this is true, this again makes contribution harder for people,
because this is different from every other ML-managed project, and creates
additional work to open your email client, and attach the patches.