From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id GJBeCNQ6R2J9QwEAgWs5BA (envelope-from ) for ; Fri, 01 Apr 2022 19:48:04 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id qOa3BNQ6R2IFqAAAauVa8A (envelope-from ) for ; Fri, 01 Apr 2022 19:48:04 +0200 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 C340E2F2E2 for ; Fri, 1 Apr 2022 19:48:03 +0200 (CEST) Received: from localhost ([::1]:39056 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1naLNS-0001eE-Vx for larch@yhetil.org; Fri, 01 Apr 2022 13:48:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51466) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1naLLp-0001cs-GL for guix-devel@gnu.org; Fri, 01 Apr 2022 13:46:22 -0400 Received: from [2a02:1800:110:4::f00:19] (port=56412 helo=laurent.telenet-ops.be) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1naLLn-0006Gi-8q for guix-devel@gnu.org; Fri, 01 Apr 2022 13:46:21 -0400 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by laurent.telenet-ops.be with bizsmtp id DVmC270084UW6Th01VmCQw; Fri, 01 Apr 2022 19:46:12 +0200 Message-ID: <447d4df82b8626181b37bedb37ba60d212cd98e9.camel@telenet.be> Subject: Re: New review checklist From: Maxime Devos To: Liliana Marie Prikler , guix-devel@gnu.org Date: Fri, 01 Apr 2022 19:46:07 +0200 In-Reply-To: References: <0912e3091c2bc34866f2795ec4f0413fc0928bdc.camel@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-CoPQFCC1gHQ8sPR6Z+a2" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1648835172; bh=AJpu96KK7lWLQYEPsNxKTofaw8BgM3LGtCyTwo3W/6A=; h=Subject:From:To:Date:In-Reply-To:References; b=QY7eU2fN5qUNlTgtpKDs8Zn8SHM9lBPDpf9LFzk+un0UsG6hvtLs7M5U23Umx3DsW kJDTT+Qj2XQUWLweojCF8+wpmdsB4UzTSv1FUbpklGZE4oxCujH6GBCRz5xeT5EDbI uq38CMV4OsQcOUKtzcnL5dGIB3qQ56HuuTJQnbDKuITesn0SpmkarXoqr9dFXvbxE4 SBgtE0BsXiQKo2b/ctCHTCdppawlRkXRLw3m6v5+qPD2ksYWXqaGaQkbAdiyzKzcUl YydLq6Z0tjXdH0mjcU9XE5naQwKUPwwf2/h8YaW4lJwrfkgg93bjPrJvwbRRIW7Kw2 OInoITbkiE3AA== X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a02:1800:110:4::f00:19 (failed) Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 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, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1648835283; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=AJpu96KK7lWLQYEPsNxKTofaw8BgM3LGtCyTwo3W/6A=; b=AOWUXMhnh8YiQSmGk9dKEtCMwkYn6mCCZ0EY9URwobrpBZm3e//x5hx+LQYJGAOiSJzzzX lhr+cBfX/LrEnvgXtctlrWhGKv5PSgjaErExq37q0tE+nRl3iKkdufkKXaQuhZUyZKIzKz rQgDVBnR0s03o+hxCfl54suPqehGMTztE4bkxyyoxqCFOwkq+mIa98lYl8pHLDihrAAKO0 yaW28UmMWtUQ554ZWBhTcUz9pXStHYd9LzjMzpYzt8Z4y2JjlH+9CJK+wAjsxOTc2kOmRJ uaQQsCMzDvR5Va4AXRVZpIybj87L2fDNK7ipjN5j0yQ/6FF5EEQkGwRqqCR5Pw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648835283; a=rsa-sha256; cv=none; b=SIDuWeMQMhxanm18boyWZUXdEYOhHRp3aQCX6gOyDbICePKict0cfdcadFQu+kqGywdVN2 XfDSz9l3RlwALbUpWc+XWfa87LrSwYd/cx3tptzNVq+HGMN7clSs2/L/DI6FaBcF13XY3p 3IHpn6t5YmiPT620/0YWkxaVOX+QGkqb343LsEcsxErCNr5SnZMyiOSz0tR6Lmvz186jty lDAzIIpxF32CnIpOizbZj2ubG45lJZqw9sTFe4IeazGIfJSF+bJxBcEJ/rpFpYmwNa1tvN SBto2gEZWJ0OIepFz6Kr5a/KgVsLrdSi9BROAtZcVjwCBd6vFZb1IOj9IeHllg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=QY7eU2fN; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -6.27 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=QY7eU2fN; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: C340E2F2E2 X-Spam-Score: -6.27 X-Migadu-Scanner: scn1.migadu.com X-TUID: 1nPK6CXIQlK1 --=-CoPQFCC1gHQ8sPR6Z+a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Liliana Marie Prikler schreef op vr 01-04-2022 om 19:03 [+0200]: > Hi Maxime, >=20 > [...] > >=20 > > -- would the commit need to be let-bound here? > This discussion has already been had elsewhere, but to reiterate, my > reasoning is that if you can't trust upstream tags to remain valid, you > need another proof that the VERSION <-> COMMIT equivalence holds.=20 > Referring to another authority (as can be done in the case of Minetest > packages) is fine for me personally, but in the general case (e.g. your > #2 without further context) I'd say that let-binding the commit leads > to the least amount of surprises for everyone. I know there have been some discussions in the past about whether git-version should be used when a commit is explicitly chosen, whether tags should be used instead of commits, how high a risk there is that version->commit can become multi-valued, =E2=80=98tricking peer review=E2= =80=99 ... However, my question isn't about any of that. It is only about the let-binding itself, in situations where the bound variable is only used in a single place. What is the reason for doing (let ((commit "cabba9e...")) (package (name "foobar") (version "0.1.2") (source (origin ... ;; this is the only use of the 'commit' variable bound in ;; the above 'commit' (commit commit))) ...)) when it can be simplified to (package (name "foobar") (version "0.1.2") (source (origin ... (commit "cabba9e..."))))? I mean, we don't do this for, say, 'name', 'version' and 'uri': ;; these three variables are only used in a single location (let ((name "foobar") (version "0.1.2") (uri "https://foo.bar")) (package (name name) (version version) (source (origin (uri uri) (commit ) [...])) ...)) Why would things be different for 'commit' here? How does putting the value of 'commit' in a let-form reduce surprises? Greetings, Maxime. --=-CoPQFCC1gHQ8sPR6Z+a2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYkc6XxccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7tpLAPsHZpH6OyDw0FiheenUnqGeSgyo bnB43VYPjDKv1vr87gEAvYkwWuwfc3HvS8ykqlZ2WiudSPYsgud6V/6GY84qOAo= =0khS -----END PGP SIGNATURE----- --=-CoPQFCC1gHQ8sPR6Z+a2--