emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: contributing to Emacs


From: Dr. Arne Babenhauserheide
Subject: Re: contributing to Emacs
Date: Sun, 18 Jun 2023 12:54:56 +0200
User-agent: mu4e 1.10.2; emacs 29.0.90

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.

¹: 
https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]