From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: contributing to Emacs Date: Sat, 24 Jun 2023 10:43:49 +0300 Message-ID: <83ttuxz4ne.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29401"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, hi-angel@yandex.ru, arne_bab@web.de, ams@gnu.org, emacs-devel@gnu.org To: Sean Whitton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 24 09:44:58 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 1qCxx4-0007Rg-Gc for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Jun 2023 09:44:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qCxvm-0001lj-4b; Sat, 24 Jun 2023 03:43:38 -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 1qCxvk-0001lI-PM for emacs-devel@gnu.org; Sat, 24 Jun 2023 03:43:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qCxvj-00081F-Mm; Sat, 24 Jun 2023 03:43:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=vy9JDOqyUe0kO1szsuEVUEY4PFg6CmJcdOzyBxtps3s=; b=ACOhiwf8sGbpSnWKTh7R PPMnZGLuqQUvhVtcVSgNbOgpDuTgMWo1VolL/ZwymYxPtnsxED/4Rk98kaw/6FiB8Hu64AnTEPs+8 Z+eOJ2Q3iUhlELm4Z/wgpsXGWlCDcO1TtgqprTUnoZS8hSi2pTCgALcJjfGht45YqWifrfvmOEIHe 9AAEuJERaOa8sQvQSkvHtXKmD+cNdM7yFD60XKqoBmS5Om62p+Zqx7MalUiB+n7q0lUXHaY3qli3a xeKufG7BX4FErFyIJGPyJoODlH713PfJmyX1ArsMXljRMf/7+7yvYt63mZMtUxOG1H4959x77UDeW 4txoeVjBoMLnAA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qCxvi-0000Je-Pf; Sat, 24 Jun 2023 03:43:35 -0400 In-Reply-To: <87edm1uxze.fsf@melete.silentflame.com> (message from Sean Whitton on Sat, 24 Jun 2023 08:21:25 +0100) 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:307175 Archived-At: > From: Sean Whitton > Cc: luangruo@yahoo.com, hi-angel@yandex.ru, arne_bab@web.de, ams@gnu.org, > emacs-devel@gnu.org > Date: Sat, 24 Jun 2023 08:21:25 +0100 > > On Fri 23 Jun 2023 at 10:17AM +03, Eli Zaretskii wrote: > > > Not in this project. Here, the preference is the opposite one (but we > > will gladly accept series as well). > > I know, I just wanted to update Po's impression of the wider ecosystem. ^^^^^^^^^ (Expect a comment from RMS for using that word.) 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'être 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.