Konstantin Kharlamov writes: > On Sun, 2023-06-18 at 13:22 +0300, Eli Zaretskii wrote: >> > From: Konstantin Kharlamov >> > 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 >> > > > Cc: "Alfred M. Szmidt" , 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