Re: contributing to Emacs

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

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.

If series is indeed unwelcome, it would be better to reflect in "sending
patches" section and provide copy-paste instructions for the people to quickly
squash their commits before sending to ML (and I think something needs to be
figured out about commit messages too in this case). Because when you are
developing, it is easier to separate changes to distinct commits to make sure
that if something break you know what exactly change was the reason to it. Even
if these commits will have to be squashed later.