From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 0HhPCIil3GG/QgAAgWs5BA (envelope-from ) for ; Mon, 10 Jan 2022 22:30:48 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id GJqtBYil3GGC8QAA9RJhRA (envelope-from ) for ; Mon, 10 Jan 2022 22:30:48 +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 B35842DA1A for ; Mon, 10 Jan 2022 22:30:47 +0100 (CET) Received: from localhost ([::1]:60794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n72FZ-0002H7-64 for larch@yhetil.org; Mon, 10 Jan 2022 16:30:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46718) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n72Es-0001wC-RN for guix-patches@gnu.org; Mon, 10 Jan 2022 16:30:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:60509) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n72Es-000829-Hh for guix-patches@gnu.org; Mon, 10 Jan 2022 16:30:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n72Es-00026j-2L for guix-patches@gnu.org; Mon, 10 Jan 2022 16:30:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#53144] [PATCH 01/13] doc: Give some tips on Minetest packaging. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 10 Jan 2022 21:30:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53144 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxime Devos , 53144@debbugs.gnu.org Received: via spool by 53144-submit@debbugs.gnu.org id=B53144.16418501558017 (code B ref 53144); Mon, 10 Jan 2022 21:30:01 +0000 Received: (at 53144) by debbugs.gnu.org; 10 Jan 2022 21:29:15 +0000 Received: from localhost ([127.0.0.1]:53412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n72E7-00025F-3c for submit@debbugs.gnu.org; Mon, 10 Jan 2022 16:29:15 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:38593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n72E2-00024w-0x for 53144@debbugs.gnu.org; Mon, 10 Jan 2022 16:29:13 -0500 Received: by mail-wr1-f66.google.com with SMTP id a5so25326099wrh.5 for <53144@debbugs.gnu.org>; Mon, 10 Jan 2022 13:29:09 -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=gpMzyVaQr0E0hAfoVi6XUM6ox1J6A9ugLEhSxA6IF3k=; b=VVtN/Gb0/fgk5wfhsXbtbSMjs5T5CFr1NaxSnXzaej+5OweT9RmgPkSiFwVqr+M1qH hnA/dhWoHZGY1ZkImk9BUjuH34lAAymYZ9DjTKU6KWOZf9psvtUfQ35iPSjNw+Tf5eME L6sxxru5mVwePWcLYDjqtcVLhnJoDEr2yYML1dJpekiB9GiNElBO6fP79Ko99PwD4VCD KdIYTsj6D8fmOZC6yJMNEGo+XI8RJuGOsEB66HUmF/Anpj9OD+hY0CVc3PUZ3XzOEeu2 8iizBCAe/2A1ffCHQ86OFzNzY6XjqAML7cqI6w0+Y98Gh4iPZZOzZgfRHjivNsc3N8VA VI6g== 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=gpMzyVaQr0E0hAfoVi6XUM6ox1J6A9ugLEhSxA6IF3k=; b=PJ/T4ND140vs6qYIvBhYxJooyJS+xYHd2s3Ca9TYcnOTkpLk22S21QEwMA/YB+NGkI NBQ70sDvPPHchTQ+SrL/XUfDQMoCvvXnSWoqGMGv8fLBIIUEZkpVt9QfSWTtmlxGwDwT qohr9Xw1ED832McpSY0G/2QOlZb+dH3wLoUDeJXv36E/6DEDW2U92CB09QeY81v7gYho 5RBHHebkVigpXP85rL8S/vbEcyL/xdriR/MCedzBBrS/VO1UlRxjaEcaaBx6+Rj9R2Xt 5GEA93i43xF+H+/wEmIP0usTnpd0rKAcaxUEpkdNrymb3bB8jUSE1CTht9Fu6XwHLxd5 drYg== X-Gm-Message-State: AOAM532Rj73pMrVU+6hl+QVBMhXqiPQxmIJAk1nhK7j/rKbC0TnR1c2r ysXAurvkv5Px2sAFpXdh0DQ= X-Google-Smtp-Source: ABdhPJzojMCaxd+S3ebv+Nu7YA5WvmnK7XrVmqy8vQbb6YGZV2iHeOqs7kYuNCUI+iebf2koQwmSnQ== X-Received: by 2002:adf:e643:: with SMTP id b3mr1217878wrn.288.1641850143905; Mon, 10 Jan 2022 13:29:03 -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 n41sm23384wms.32.2022.01.10.13.29.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 13:29:03 -0800 (PST) Message-ID: From: Liliana Marie Prikler Date: Mon, 10 Jan 2022 22:29:02 +0100 In-Reply-To: <26497fddb211ac9913dd60a5927dd4ab4f9fae0d.camel@telenet.be> References: <20220109191015.33058-1-maximedevos@telenet.be> <26497fddb211ac9913dd60a5927dd4ab4f9fae0d.camel@telenet.be> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" 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=1641850247; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=gpMzyVaQr0E0hAfoVi6XUM6ox1J6A9ugLEhSxA6IF3k=; b=KWOpVXwiPw3n41CHs/FgBp69OEP7Bo7pe6ygn8KMcwJSMZ/TA3lwCJxTdCd8SDi+Ba7gEF 6EsB363X4WruXgvoOtyEiXXs99eprmVdD8f9Jx19Og3rP45jhsOMJhvTZdpUKZJjPbdEJO +G9qLYL8Yfbhpmf/wIg34WaMral8RTX4oeZo+KctQl6IXAXqlOc5g7I3sapNXpEgov1/R0 TfCBJat8sr/6TIgvXXyiETUMPbUYHQwq/dheZW5PYiWXWCJVUKB6zuWb9U1TW7hkXLk84a sT/jVbhai0igtt1Oq1L9997jfXnWcvSx9Q/StIWdpiupGIDF6/Orclv6dm5j3A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641850247; a=rsa-sha256; cv=none; b=b52DsEKJCCEaclfOu51AFg/0ClFvRJ8KfON/FQPe5JdBShdnOFvAUzXqobcORK2xMXLpUR Frp8ktUKXekc4P0lok3Rt+cERVYkcvSZKVkKUy5qG/E7yQP+w7eHYfSOVcbxM8FBcoG31X liZEL8JpH1i3s8/bSwCNjjbI3M9Y5789D07D+hNPrZ0T55rOdmFLZqZjhkcDrISNmipnnc MomN4QMyraMLHpAkw9NkiY8Y7tqNEjvbW36BPbDBeeMDwAUnQPqJINJzn+6i3vDIqkYOPN ZlCrAFnK/6px2Hjx+RSzA0TKJW8PN/O8sTss3+RqsPJ3QWMeS8z+kUZgdxH/xg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b="VVtN/Gb0"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.11 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b="VVtN/Gb0"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: B35842DA1A X-Spam-Score: -4.11 X-Migadu-Scanner: scn0.migadu.com X-TUID: tbKKSfWiqMCX Hi, Am Montag, dem 10.01.2022 um 00:29 +0100 schrieb Maxime Devos: > Liliana Marie Prikler schreef op zo 09-01-2022 om 22:15 [+0100]: > > [...] > > > + > > > +Sometimes, it might be unclear what the version of a Minetest > > > mod > > > is. > > > +For example, ContentDB and the importer reports 2020-01-01, but > > > +according to the forums the version is 2.1.  Usually, in these > > > cases > > > the > > > +version on ContentDB is the newest and intended for > > > distribution. As > > > +such, you can use the version from ContentDB without any special > > > +comments. > > We might want to quote an authoritative resource on that, perhaps > > in the footnote? > > Yes, quoting sources seems good. > > About newest version: I don't have an authoritive source at hand; > this is more speaking of my own experience of what seems to be the > case. I could compute some statistics w.r.t. how often is the latest > version on ContentDB >= latest tagged version in the repository > (where > is the is-(indirect)-child-commit-of relation, as the > versions strings aren't always directly comparable -- see discussion > about CalVer vs. SemVer and ContentDB sometimes using CalVer and > sometimes SemVer). > > This also seems a consequence of ContentDB being the official source > of mods and used by Minetest's built-in installer. > > About ‘intended for distribution’: I'll look for a forum post or wiki > page targetting new mod authors that want to distribute their mod. > > What do you think of me gathering this information and (if not > falsified) presenting it to upstream in some public location, > asking if it seems about right, and (presuming they answer ‘yes’), > quoting their response? In my opinion the fact that Minetest's built-in installer serves as this ‘M-x package-install’-like gateway would already be authoritative enough, but it still deserves being spelled out in a footnote that this is the basis of our assumptions :) Communicating with upstreams is also important, but a poll or similar would be significantly harder to quote (perhaps we could insert it in a comment), and that's not even talking about what we'd have to do to account for input selection. > > > I happen to disagree though, being mostly neutral about > version+commit with a slight preference towards including the commit > itself in the commit field of 'git-reference' (and not a tag pointing > to the commit), because it is more explicit and it fits slightly > better in some nebulous plans for decentralising source code > downloading/storage.  There are ‘tricking peer review’ issues > with this though, hence neutral. > > (See if interested) > > Hence, adding something like ‘This is specific to Minetest packages, > for other packages it is advised to use git tags, see [...]’ doesn't > make much sense to me, though I understand why it would make sense > to you.  Furthermore, the reference [...] currently doesn't exist, so > I cannot point the reader to an explanation why for other packages we > want git tags and not commits. Again note that you're not only competing against version+tag, but also against git-version+hash, with git-version embedding the hash. Among Guix packages, Minetest *is* rather unique in having a separate source (ContentDB) pointing to the bespoke commits that serve as release basis. > If there was consensus (one way or the other) and some section in the > manual explaining what should usually be used (tags or commits) > (preferably also explaining the reasons and not simply stating > things), I could link to it though.  Or if there's no consensus, and > the section said something like > > ‘There are two options: tags or commits.  Currently there's no > consensus about what's best.  Here are some pros and cons of each: > ... > Due to a lack of consensus, the patch submitter can make the choice. > When in doubt, throw a dice.’ (*) (to be reworded!), > > then I could work with that as well. > > Perhaps I could write out (*) a bit more, as a separate documentation > patch?  I'd have to ask on guix-devel@ if I'm > understanding/misunderstanding the lack of consensus, and see if > someone has already summarised things, maybe see if Nix people > have thought about this, etc. One question whose answer is not quite clear to me is whether you want to generally follow the commit vs. tag guidelines of the rest of Guix (and therefore seek to formalize them in a similar way, though perhaps with different reasoning from what I do), or if you want ContentDB packages to follow their own style largely independent from the rest, at least for the time being. > > Perhaps setting a package-property such as (upstream . contentdb), > > which would also make it clear why we don't e.g. want the latest- > > git updater to apply? > > More generally, being able to explicitely choose the updater > (minetest/github/elpa/...) seems useful! > > However, in the context of this documentation section and the changes > to the ContentDB importer, I don't think latest-git is relevant here > (except for the infrequent edge cases like minetest-throwing-arrows > and emacs-next): we almost never want the latest-git updater to apply > (because formal releases etc.).  And when we do want it to apply, we > set > >   (with-latest-git-commit . #true/"refs/heads/master"/...) > > otherwise latest-git doesn't run.  Well, we don't do that yet except > for minetest-throwing-arrows, but that's the idea. I think the generic git updater would still be relevant here, hence why I'm asking. Yes, latest-git is restricted in that it needs opting in, but the property combination ((upstream . latest-git) (latest-git-head "master")) would also work, for example. > To summarise, I don't see the value that adding (upstream . > contentdb) would bring, it seems to me that it would only make the > package definitions longer.  Would this package property be pure > documentation, or would it be interpreted by the updater code in some > way? Ideally it'd serve as a better way of making the minetest-updater say "Now this looks like a job for me" than relying on the minetest- package? procedure. Alternatively, we could make it so that the updater has to have a contentdb URL as homepage. You are correct in that there's no immediate benefit, but given that we would be shortening a four-line comment to a single-line property while essentially keeping all the information is still a win in my opinion. > > Otherwise LGTM. > > I'm not complaining, but from > > and resulting discussion I was kind of expecting that you'd > want me to do > > (let ((commit ...) >       (revision ...)) >   (package ... >     (version (git-version "contentdb-version" revision commit)) > ...)), > > though you did write ‘I'd want a comment like the ones I find in > minetest.scm to [...]’ I suppose, and this new documentation is > explaining the reasons for using commits (raw commits in your > terminology) in some detail and for all Minetest packages at once. It does, but in a different location that requires a little bit of work to do the mapping. I think a comment line  ;; version from contentdb or similar would still be appropriate even with said documentation changes. Alternatively, as pointed out above, we could have home-page point to ContentDB, which IIRC should also present that information to the user. I think "Can we use ContentDB as a home-page for minetest-blub?" also serves as a good leading question on what source is the most authoritative one. If the ContentDB page looks ill-maintained, but the forum is active, the forum should probably be preferred (while "generally, use ContentDB" still applies otherwise). The distinction between "raw commits" and just commits is also an important one that I want to keep. ContentDB provides both release titles and commits in a usable format, so that's why raw commits are in this context permissible in my opinion. There's no ContentDB for guile-aiscm or node-something-that-loses-its-git-tag. Cheers