From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.devel Subject: Re: contributing to Emacs Date: Sun, 18 Jun 2023 13:27:47 +0300 Message-ID: <73cbe80096cd97728fcdaccf9f9badeea606570b.camel@yandex.ru> References: <83v8fnslfz.fsf@gnu.org> <87v8fnh1h2.fsf@web.de> <83mt0zs9rc.fsf@gnu.org> <0a968a4e1b267c0f15dd237e6ea12a709fc06d5e.camel@yandex.ru> <838rcisj7o.fsf@gnu.org> <6537fa5fa5c1fe8437ed99ee0988e35895f5a54b.camel@yandex.ru> <8423a35750d8d8e0437c7708f6b4d0bbdfdb7fe0.camel@yandex.ru> <87o7ldf7ky.fsf@web.de> <8cc19084ab18d0adb0f2cee4af14aa1b1d914a83.camel@yandex.ru> <83sfapnl57.fsf@gnu.org> <83pm5tnk78.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11955"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.48.2 Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 18 12:28:07 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qApde-0002ro-I4 for ged-emacs-devel@m.gmane-mx.org; Sun, 18 Jun 2023 12:28:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qApdV-0002eX-C7; Sun, 18 Jun 2023 06:27:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qApdR-0002aJ-Va for emacs-devel@gnu.org; Sun, 18 Jun 2023 06:27:54 -0400 Original-Received: from forward500a.mail.yandex.net ([2a02:6b8:c0e:500:1:45:d181:d500]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qApdP-0002dE-H1; Sun, 18 Jun 2023 06:27:53 -0400 Original-Received: from mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1d:63cd:0:640:4ab5:0]) by forward500a.mail.yandex.net (Yandex) with ESMTP id BDA545E922; Sun, 18 Jun 2023 13:27:47 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id lRcIF3YDRiE0-pR30Icrv; Sun, 18 Jun 2023 13:27:47 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1687084067; bh=zGBfRX+dm72atpy8Acwq3bA/VfRS7xFMvUM56MeP3Kg=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=JJYU9/IO+L9Oi3puq+acXsv3IRDzbjj3fOX5zHkp6c0soK1UcZ77Nm2ZCGqn8q2h4 mqhtDwqoAfTQ4k2NWLXw267StuiD2tedZH0wuON48jbIHCKyGd9hngtcp8oM10LS8j 5vpA7WpSDogKFjP42s/mTGfvRxZddkgyj7hlbLp4= Authentication-Results: mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru In-Reply-To: <83pm5tnk78.fsf@gnu.org> Received-SPF: pass client-ip=2a02:6b8:c0e:500:1:45:d181:d500; envelope-from=hi-angel@yandex.ru; helo=forward500a.mail.yandex.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306955 Archived-At: 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.o= rg > > Date: Sun, 18 Jun 2023 13:13:23 +0300 > >=20 > > 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,=20 > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0emacs-devel@gnu.org > > > > Date: Sun, 18 Jun 2023 12:56:33 +0300 > > > >=20 > > > > 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. > > > >=20 > > > > In ML-managed projects it is typical to send patches as a series, a= nd > > > > when > > > > you > > > > doing that results in such surprising behaviour, it creates an > > > > additional > > > > emotional and mental load both for you and for maintainers who woul= d > > > > need to > > > > do > > > > something with these separate reports. > > >=20 > > > Our preference is to send patches as a single patch, not as patch > > > series. > > >=20 > > > That said, people are sometimes sending series, and we don't ask them > > > to resend, we process those series anyway. > > >=20 > > > As for separate bug reports, this is easily fixed by merging them. > >=20 > > Unfortunately merging bugreports does not fix that. The last patch I ha= d 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 =CE=B1) discussions happened on both threads, b= ut then a > > new > > patch version was only sent to one of them, so there other thread wasn'= t > > notified that comments were addressed, and =CE=B2) you may remember 3 m= onths > > 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 o= ther > > thread into which a person was looking has no such comment. > >=20 > > > So I see no problem here. > >=20 > > 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 li= ke > > something just went wrong. Such situation being okay needs at least be > > mentioned > > in "sending patches" section, and at best it should just work. >=20 > Like I said: we prefer a single patch for each changeset.=C2=A0 The > problems presented by patch series are one reason.=C2=A0 And yet, we will > never reject a patch series, even though it makes the process > inconvenient and confusing. >=20 > 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 i= s 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 quic= kly squash their commits before sending to ML (and I think something needs to b= e 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 su= re that if something break you know what exactly change was the reason to it. = Even if these commits will have to be squashed later.