From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Whitton Newsgroups: gmane.emacs.devel Subject: Re: contributing to Emacs Date: Sun, 25 Jun 2023 08:39:30 +0100 Message-ID: <87v8fct2h9.fsf@melete.silentflame.com> 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> <87352p9izj.fsf@yahoo.com> <87pm5mvfgi.fsf@melete.silentflame.com> <83v8fe1wcm.fsf@gnu.org> <87edm1uxze.fsf@melete.silentflame.com> <83ttuxz4ne.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="12373"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: luangruo@yahoo.com, hi-angel@yandex.ru, arne_bab@web.de, ams@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 25 09:40:46 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 1qDKMW-00031I-9F for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Jun 2023 09:40:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qDKLU-0005sq-62; Sun, 25 Jun 2023 03:39:40 -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 1qDKLT-0005sf-GI for emacs-devel@gnu.org; Sun, 25 Jun 2023 03:39:39 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qDKLR-0003Fr-6m; Sun, 25 Jun 2023 03:39:39 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5ED175C00E9; Sun, 25 Jun 2023 03:39:33 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 25 Jun 2023 03:39:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1687678773; x=1687765173; bh=5nmtmb7T7TA6bxnUUIJ3q2V2i CETcHvLyCDIyZ03jlg=; b=R4JaUGLaN11yprhkMoyBqM5yCrpL95+C2pMiZzKG5 FZxKsgtYhbJRqLpjxRrNRIHwKN18bIhvG5wIYgd1mvhGi+cuo6eZMzVy8wtVxQR6 ifhrUbhjRQI1YC69Bt1xVSmEkl0/QxbJ1NQ/PgkddnNVaAm6TYAqTXH9+h70PU5o tvCiljgy+6d0HO9YHBN7NhWjmGJ+/35xCR+ILwQkZEZMdGdkyIojXgaqQLf0MgJq I7o/rXqmvkpObSjQbzqxV5DUWdtog0J7/piic7EvQyKOJ8AeBi8jHsvait9lmkOA /lDbcpsDHF5G87d461WXpJ9pmnj7TGG4rDeT3PkgOEKdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1687678773; x=1687765173; bh=5nmtmb7T7TA6bxnUUIJ3q2V2iCETcHvLyCD IyZ03jlg=; b=Xd+pOoOXVsrbGSri/e03y2k2oGHh2R3oS4EzcNprA4iExdQLBuC l6n1NlXNWluCXOnDcrsBlUhHiixoIvk/qQp7lqyAzXp0Kmh7dY0XLrXTzqbGkHU+ uJDU3FWRsFOR4i7xCCrcmncpO8e3cZlu+O9CxHVWFhV5e1SOscK59zEysHULy5NF xI0pguBkjcJaUhIfbEShPd9em4oSZsRtSxbqqhjPMS1ojOJ8uShLoXYwV0KonopZ rh+hDDS3iH4kS8LECOLHjlxTFJXe3oMJUflpuQZ7G7a7viEHmK3Gdh+XFd+bpkPo YpqK4pnUJIHZWSMxiVcuHPZNbvDSOvLGGgQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgeegledgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefujghffffkfgggtgfgsehtqhdttddtreejnecuhfhrohhmpefuvggr nhcuhghhihhtthhonhcuoehsphifhhhithhtohhnsehsphifhhhithhtohhnrdhnrghmvg eqnecuggftrfgrthhtvghrnhepffefhfejudeguddtudekjeekueevvedvieeghfegleet uefhkeegkefhleejvddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepshhpfihhihhtthhonhesshhpfihhihhtthhonhdrnhgrmhgv X-ME-Proxy: Feedback-ID: i23c04076:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 25 Jun 2023 03:39:32 -0400 (EDT) Original-Received: by melete.silentflame.com (Postfix, from userid 1000) id 0EC6A7E1912; Sun, 25 Jun 2023 08:39:30 +0100 (BST) In-Reply-To: <83ttuxz4ne.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Jun 2023 10:43:49 +0300") Received-SPF: pass client-ip=66.111.4.27; envelope-from=spwhitton@spwhitton.name; helo=out3-smtp.messagingengine.com 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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:307210 Archived-At: Hello, On Sat 24 Jun 2023 at 10:43AM +03, Eli Zaretskii wrote: > The problem with that preference is that most contributors > misunderstand how to arrange the series correctly, and end up sending > series which require extra work, because the same places were modified > several times. On top of that, the series doesn't really allow > applying only some of the patches, which is the main raison d'=C3=AAtre of > the technique. > > To correctly subdivide a large patch into a series, one must identify > changes in the changeset that are (a) independent, i.e., can be > applied without all the rest, and in any order; and (b) changes which > _make_sense_ as separate changes, so the project might consider > applying just them, even though the rest will be rejected. > > What most people do instead is they provide a series where each patch > is a step towards the solution. First, a patch with some refactoring, > then another patch with the first aspect of the solution, another > patch with the second aspect, etc. Such series make no sense as a > series, because the patches are not really independent; instead, they > are _incremental_. For example, it usually makes no sense to do the > refactoring if we aren't installing the changes which need it. > Moreover, this technique frequently leads to multiple patches touching > the same places several times, so when you review the first patch, you > are looking at code that will be modified later, and risk providing > comments that are irrelevant, because a later patch in the series > rewrites that code anyway, perhaps exactly in a way that you want to > tell the contributor to use. Basically, the only sane method of > reviewing such "series" is to apply the entire series, then produce > the unified diffs from all of them, and than review those diffs > instead of the patch series. > > Since the correct way of breaking patches into individual ones is hard > to explain, and requires good knowledge of the project's conventions > and practices to determine how to break the large patch, I find it > easier to ask contributors to not bother with series and submit a > single large patch. IME, it's TRT in the majority of cases anyway, > especially with contributions that provide some minor change or fix, > and it definitely makes patch review much more convenient and easy > than the opposite preference. This all makes sense. Separating changes usefully is a skill that people have to acquire. And it's reasonable to conclude from experience that enough people get it wrong that it is better to ask people not to do it at all. I do disagree that the main reason for separating them is to allow applying only some of them. I think making review easier, and improving the level of detail in the VCS history, are more singificant reasons. --=20 Sean Whitton