From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <guix-devel-bounces+larch=yhetil.org@gnu.org>
Received: from mp11.migadu.com ([2001:41d0:2:bcc0::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms0.migadu.com with LMTPS
	id OK7EIjCy0WHynAAAgWs5BA
	(envelope-from <guix-devel-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sun, 02 Jan 2022 15:09:52 +0100
Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp11.migadu.com with LMTPS
	id CPoeIDCy0WHY3wAA9RJhRA
	(envelope-from <guix-devel-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sun, 02 Jan 2022 15:09:52 +0100
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 DD26812E4B
	for <larch@yhetil.org>; Sun,  2 Jan 2022 15:09:51 +0100 (CET)
Received: from localhost ([::1]:32870 helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <guix-devel-bounces+larch=yhetil.org@gnu.org>)
	id 1n41YU-0006Ly-Qr
	for larch@yhetil.org; Sun, 02 Jan 2022 09:09:50 -0500
Received: from eggs.gnu.org ([209.51.188.92]:36914)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <liliana.prikler@gmail.com>)
 id 1n41Y3-0006La-8I
 for guix-devel@gnu.org; Sun, 02 Jan 2022 09:09:23 -0500
Received: from [2a00:1450:4864:20::443] (port=46000
 helo=mail-wr1-x443.google.com)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <liliana.prikler@gmail.com>)
 id 1n41Xy-00085C-Bt
 for guix-devel@gnu.org; Sun, 02 Jan 2022 09:09:19 -0500
Received: by mail-wr1-x443.google.com with SMTP id v7so64991188wrv.12
 for <guix-devel@gnu.org>; Sun, 02 Jan 2022 06:09:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=message-id:subject:from:to:date:in-reply-to:references:user-agent
 :mime-version:content-transfer-encoding;
 bh=DZ+KepfQVsZggSxrutFH6VKgxvSUQuOve5uVxlH7KsE=;
 b=pCEZORhNuqqstZZSfVDxFST4AVhs7mXFtJr2xe13QkdyoFFQ/XL3OcSqqFAAqCn/2G
 sNN/M21FG8LNC7sVV0pO2QFQUaNw6ZehXRUHmxO+0FGb7dgLnKW+TO0JGjKdTEIFZ/CK
 QCZOfF0oBzbrI++l1FTz4M9/RAGudmRABdh+JWL1FEzeh+Ts7cwga/gVPkRGGPn54DIt
 b6dDrx7DtaC9dYx4hToMNRfRk7wjDbKH3b33Scyzjk8t7t4EGuyxwxLz6Nba01soHPFP
 6sdc5H6cT4FWoGH6Jd2PljzdSBYwF5KWWE1PCsyPnY5jm7Y+OyijiDjCvs7/gHEsK3p/
 97+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to
 :references:user-agent:mime-version:content-transfer-encoding;
 bh=DZ+KepfQVsZggSxrutFH6VKgxvSUQuOve5uVxlH7KsE=;
 b=IPzFxh8jMwhgYpwcS/bd4xgnDTblH70tBtL7O1wjZJce9GDjYNEwF7WsDMcfkKifVz
 7LKvkHD4Jwm/4uyRyXBT7wzhW2Ky+MGqP3HVOAZXWbwTk1TUhjs9SM4tBgyG2kjG3Fd1
 jQSHnlMnwZwTN1IXVyyUUqKzAu2tVamEe6TOP+7IY4nPZBi2WNL/msXnbRk7Hg7d3VE5
 8qEkDLtu5TDTCqBlNguyCeWrWNrM/4seLgE/Z1+Xhm91R5H0xReP8LWGnRu5aZEelSDK
 eg8OrwSYhj6070CddVNfXSMxScW0IwkVXbXDvTcKwH03l898BThlkmOJM67PlXhkRIx4
 cDig==
X-Gm-Message-State: AOAM532cyu6Po0sSnKm0CalljDfTrLimcqTnDas8y9sRqxFew3HIOmFt
 l3VHj4e9Tj9opAH/82OyV3MyJL7Y+cqZpg==
X-Google-Smtp-Source: ABdhPJyhfowze4RG8dHdcXui6XX+lSDgHvKVAD2H/8p16bfdRUsVijk59LClmu+RhMW7itIgrbr3Cw==
X-Received: by 2002:a5d:47cb:: with SMTP id o11mr35376952wrc.686.1641132557170; 
 Sun, 02 Jan 2022 06:09:17 -0800 (PST)
Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at.
 [85.127.52.93])
 by smtp.gmail.com with ESMTPSA id bg19sm10778404wmb.47.2022.01.02.06.09.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 02 Jan 2022 06:09:16 -0800 (PST)
Message-ID: <26d26a82e8503df230c5cf9a48aa9f2c5277e09f.camel@gmail.com>
Subject: Re: On raw strings in <origin> commit field
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Mark H Weaver <mhw@netris.org>, guix-devel@gnu.org
Date: Sun, 02 Jan 2022 15:09:15 +0100
In-Reply-To: <87v8z2b9yz.fsf@netris.org>
References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com>
 <87k0fm7v3k.fsf@netris.org>
 <fea5818257247fce727d4c5178b830b1a06eb8b7.camel@gmail.com>
 <871r1smdu6.fsf@netris.org>
 <b72eb9430694fe7bccb6b37f9cfce7d8e47f1385.camel@gmail.com>
 <87tuenky2x.fsf@netris.org>
 <b3bfa7b57b527d78aeb21dee6123c617a90fc13d.camel@gmail.com>
 <87v8z2b9yz.fsf@netris.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::443
 (failed)
Received-SPF: pass client-ip=2a00:1450:4864:20::443;
 envelope-from=liliana.prikler@gmail.com; helo=mail-wr1-x443.google.com
X-Spam_score_int: 6
X-Spam_score: 0.6
X-Spam_bar: /
X-Spam_report: (0.6 / 5.0 requ) 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_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 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."
 <guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/guix-devel>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+larch=yhetil.org@gnu.org>
X-Migadu-Flow: FLOW_IN
X-Migadu-Country: US
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org;
	s=key1; t=1641132592;
	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:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:list-id:list-help:
	 list-unsubscribe:list-subscribe:list-post:dkim-signature;
	bh=DZ+KepfQVsZggSxrutFH6VKgxvSUQuOve5uVxlH7KsE=;
	b=kN5ehMUAuDAoZJdnCnMQUL/McXxomtwnQ/QQQny+pPlFuSyCYUpw+Hxsg/HJ7o4vU0eSrl
	OA5dfHn8Z25URjG7LOUW5Hjr5g3Ej5Lnxagf8i/UesaSI2akmsLh7R412lPB3MVO39kdkt
	KXWVLmkjdpmT9+kwz5ainl/tQI+5VKFod90SyZLMYG4CsUGg+bD9aBHU9R04iJmRhau2sd
	T/SnJbufJEfV/uW+u2pRs0jTIMjRPOKczkeybAYU/ifsVXfcGXvUe+YNDRA9CwjKiLL14j
	AgAfGIdYCGwwF8GZ1c/xd0zwQlQZ+OxNQj6xrPnzVw0QOMFiDr5RgmUUS7sfOw==
ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641132592; a=rsa-sha256; cv=none;
	b=fBkY9KBVSQW85xjq22Nm1+J8P+PJjZ8eKPx8YTrCzmbB3A5oEv9BCeEf6DBNPdZKFj0Vc3
	gmqwC0nWdzRnKe4FGl93IV/rR8XOJL5wSVkNyYkmXcpQP7f862KqB3HJMwVy39KZcUPNT8
	xhRvnlhUP8/b+Oq+GEgIy79Y3ouZYW8rVJ0SMlUJybaepIlnvY8kCb63XUgxbYgOHBPYeU
	MCBd2lQ7VIgQgRD5fuZ49eeHQCcgx1YqJ7syPC60uj/VRf8m3ohwfOj0U6IAHEItpda4+Y
	vIwKG0AT11SsB3dayLwDoPBi/KG4ZA3l9E3mDv3wjN/46+jcave4r6u/xB1SyQ==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=pCEZORhN;
	dmarc=pass (policy=none) header.from=gmail.com;
	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.08
Authentication-Results: aspmx1.migadu.com;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=pCEZORhN;
	dmarc=pass (policy=none) header.from=gmail.com;
	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: DD26812E4B
X-Spam-Score: -6.08
X-Migadu-Scanner: scn0.migadu.com
X-TUID: eAdbJ8crzU4q

Hi Mark,

Am Sonntag, dem 02.01.2022 um 07:25 -0500 schrieb Mark H Weaver:
> Repeating myself: our difficulties understanding each other on this
> point might be due a translation issue.  Earlier, you wrote:
> 
> > And here I disagree.  This reasoning presupposes that we have to
> > ensure that the package still points to the same commit if the tag
> > changes, which itself presupposes that the tag does change.
> 
> and I replied (quoted above) "I disagree with the last line above".
> 
> However, I'll note that a single-word substitution would eliminate my
> objection.  If you substitute "might change" or "could change" in
> place of "does change" in the text above above, then I would more-or-
> less agree with what you wrote.
> 
> In English, the phrases "could change" and "might change" indicate a
> /possibility/ of change.  In other words, they indicate an absence of
> knowledge about whether change will occur.
We can agree on an absence of knowledge, but an absence of knowledge is
not an absence of assumption, which is why I'm making a stronger
statement than what you agree with.

> On the other hand, "does change" suggests to my ears (as a native
> English speaker) that change is /known to occur/.  In other words, if
> you say "X does change" and then X is observed to remain constant
> over some suitably long time interval, that would call into question
> the veracity of your words.
It's not quite as harsh, since either way we are making predictions
about uncertain events in the future.  We could for instance make a bet
on a given package, whether a given tag will be moved/dropped within
1/2/5/10 years and whoever wins gets the commit in which we updated the
package description as NFT, bragging rights, or something similarly
trivial.  There is no such thing as absolute truth to either statement
(the tag changes/does not change), there is only an observation whether
one or the other holds in past tense at a given point in time.

> To give an example from the Scheme programming language, if you
> showed me the following code template:
> 
>    (let ((LST '(1 2 3)))
>      <body>)
> 
> I would say "LST could change".  I would *not* say "LST does change".
Whether or not LST changes obviously depends on BODY here, but this
form is ill-suited to draw comparison.  C++ const (correctness) would
be closer to what we're discussing, as would be the following Scheme
code inside a module:

  (define LST '(1 2 3))
  (define (F) (peek LST))

Let's assume that some outsider redefines LST to '(4 5 6).  What would
be the value printed and returned by F?  This depends on whether the
compiler was optimistic and inlined LST or pessimistic and did not
inline it.  In either case, the compiler makes an assumption about
whether LST *does change* and it can be wrong.

> With this in mind, here are your words again:
> 
> > And here I disagree.  This reasoning presupposes that we have to
> > ensure that the package still points to the same commit if the tag
> > changes, which itself presupposes that the tag does change.
> 
> In the last line, you're telling me that my reasoning "presupposes
> that the tag does change", which to my ears suggests that you think
> I'm assuming that _every_ tag will be mutated sooner or later.
> 
> If, instead, the last line above read: "which itself presupposes that
> the tag *could* change", that essentially means that I'm preparing
> for the /possibility/ of change, which is true.
"Tags in Git can change" is not an assumption that one person can make
and another dispute.  It is a fact/rule/whatever given by Git, that
they can.  In a similar manner, it is a fact, that servers can move to
different locations in both geographical and virtual address spaces and
can over time serve different content.

The question is what policies we derive from said facts, which is a
typical is/ought dilemma.  Since at this point we are far removed from
facts that we can state with certainty, we have to instead rely on
assumptions, whether they come from experience, gut feelings or an old
lady with a crystal ball down the street.  

This does not mean that you assume each and every tag out in the wild
changes every few commits to the Guix repository.  But it does mean
that you find it likely and/or troublesome enough to warrant a policy,
which in turn is based either on the assumption that it is likelier to
change than not or some ad-hoc justification to bet against the odds as
well as a rough assumption on said odds.  It's like asking someone to
estimate whether the glass is full or empty, but with the added bonus
that we don't even know how much water it contains.

Now I am very open about my assumption that tags won't break for a
large number of packages.  I can also understand if you make a
different assumption for one package out there and thereby justify
using git-version, and there's even an argument to be made that all
git-based ought to use it by generalizing that assumption.  But you
cannot assume both to hold at the same time without being inconsistent
and there's nothing meaningful to derive from not knowing because
you'll make a guess either way.

Cheers