From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id IBnbGBBSyl8dcwAA0tVLHw (envelope-from ) for ; Fri, 04 Dec 2020 15:13:20 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id qPqnFBBSyl8ULwAA1q6Kng (envelope-from ) for ; Fri, 04 Dec 2020 15:13:20 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0682F940484 for ; Fri, 4 Dec 2020 15:13:19 +0000 (UTC) Received: from localhost ([::1]:44248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1klClq-0000Q9-Te for larch@yhetil.org; Fri, 04 Dec 2020 10:13:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37192) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1klCld-0000Pm-Qx for guix-devel@gnu.org; Fri, 04 Dec 2020 10:13:05 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:50818) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1klClb-0003wA-Cd for guix-devel@gnu.org; Fri, 04 Dec 2020 10:13:05 -0500 Received: from localhost (80-110-125-229.cgn.dynamic.surfer.at [80.110.125.229]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 1D4D83362F06; Fri, 4 Dec 2020 16:13:00 +0100 (CET) Date: Fri, 4 Dec 2020 16:12:57 +0100 From: Danny Milosavljevic To: "Raghav Gururajan" Subject: Re: Questionable "cosmetic changes" commits Message-ID: <20201204161257.64363a5a@scratchpost.org> In-Reply-To: References: X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/EHXVZT5xWH=iMuYu.njqWLw"; protocol="application/pgp-signature"; micalg=pgp-sha512 Received-SPF: none client-ip=85.13.145.193; envelope-from=dannym@scratchpost.org; helo=dd26836.kasserver.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Development of GNU Guix and the GNU System distribution , Ryan Prior Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.39 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 0682F940484 X-Spam-Score: -2.39 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: nJ3UqinS6DEl --Sig_/EHXVZT5xWH=iMuYu.njqWLw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Raghav, first, let me say that as far as I'm concerned, you did nothing wrong--alth= ough it caused a lot of work for you to do the rearranging in the first place (and also some work for us). Guix irregularities also annoy the hell out of me. You can check out some earlier patches by me (when I joined the project) in the archives. I wanted (and still want!) to rearrange a LOT of stuff--because, let's face it, Guix= 's module layout in general is a mess. But for better or for worse, it's not easy to do anything about it and also keep backward compatibility with what external projects expect of Guix and also keep using the tools that we have been using so far (git, diff, patch etc). So even though I still would prefer Guix module layout not to suck, it cannot be changed in the short te= rm. So I know where you are coming from. But in general, arguing about *formatting* is bike-shedding at its best, especially in a language where formatting does not matter. However, we do use textual diff, blame and merge tools--and those do not understand the tree structure of a Lisp program at all. Rearranging stuff especially will (and did) cause diff and patch to mistake the insertion point for changes. (It will patch it wrong if applied out of order or when skipping patches--and will often NOT fail) So for example it's very difficult to leave off the cosmetic patch and just apply the non-cosmetic patches that came later. Furthermore, understand that the package fields (and guix record fields in general) can refer to previously defined fields--so a package with reordered fields is NOT necessarily semantically equivalent to the original one. Try these in guix repl: (let ((name "OUTER")) (package-version (package (name "INNER") (version name) (source #f) (build-system #f) (synopsis #f) (description #f) (license #f) (home-page #f)))) (that gives "INNER") vs (let ((name "OUTER")) (package-version (package (version name) (name "name") (source #f) (build-system #f) (synopsis #f) (description #f) (license #f) (home-page #f)))) (that gives "OUTER") That means each cosmetic patch of you required some extra manual review eff= ort by me in order to make sure that this does not introduce semantic changes. That said, if people post reformatting patches (especially if part of a pat= chset that was presumably already tested by that person) I usually do not say any= thing about it because I don't want to cause extra work that is useful to nobody = (and potentially invalidate all the testing done). FWIW, I do find it strange that Lisp projects, despite using a minimal-synt= ax language (mostly in order to conserve its regular tree structure), do not usually automatically format source code as they check in, but Go projects, using the prime example of an irregular C-like language, DOES usually use code formatters automatically when checking in. That is some strange reversal of strengths that I wouldn't have expected. --Sig_/EHXVZT5xWH=iMuYu.njqWLw Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/KUfkACgkQ5xo1VCww uqUuMwf9HoXvDv88UvDjLvNoJxSdaolc5AX6ejUWUD66JBOtrLwLPZCIHHcHt6fQ 0XnIF2TlG9hb3eyMK1irQeo3JB16obSKfceEL9ndWIDOFnZVQeG8KRQgiNbiv9mT OcyNAfjI03nsjVomizIWMyI72AWN45FVYRfHgy0sU+pEP4gLHcGdSa79AWZaWOok iYHxs/p0+/heHe06PlD3k1F9yftLCx4KpMjBjKPDXU9BqodnkdH1AUvqXBrBejQ0 UHk0erkV12IC67dHYAgJa8b3n6rytvP5TkmwVSKMghCphNZFSQDc2oloG3N9CgpH D2W+pY69A/0Hq/UGOm++9q+zyIkWYw== =KOVG -----END PGP SIGNATURE----- --Sig_/EHXVZT5xWH=iMuYu.njqWLw--