From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 09 18:29:48 2022 Received: (at 53144) by debbugs.gnu.org; 9 Jan 2022 23:29:49 +0000 Received: from localhost ([127.0.0.1]:51545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6hdE-0007mF-Fn for submit@debbugs.gnu.org; Sun, 09 Jan 2022 18:29:48 -0500 Received: from michel.telenet-ops.be ([195.130.137.88]:45488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6hdB-0007m3-A8 for 53144@debbugs.gnu.org; Sun, 09 Jan 2022 18:29:47 -0500 Received: from [172.20.10.5] ([188.188.14.77]) by michel.telenet-ops.be with bizsmtp id gnVi2600G1flEHY06nVipR; Mon, 10 Jan 2022 00:29:43 +0100 Message-ID: <26497fddb211ac9913dd60a5927dd4ab4f9fae0d.camel@telenet.be> Subject: Re: [PATCH 01/13] doc: Give some tips on Minetest packaging. From: Maxime Devos To: Liliana Marie Prikler , 53144@debbugs.gnu.org Date: Mon, 10 Jan 2022 00:29:37 +0100 In-Reply-To: References: <20220109191015.33058-1-maximedevos@telenet.be> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-NcbWOD66Ig+udZ2IPxBH" 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=1641770983; bh=2QJhBUD6vvISKkBQ31iG4PSfRpO3MqrEJ+WZXRshs5w=; h=Subject:From:To:Date:In-Reply-To:References; b=c09za5EbwDJekUl8NsgHk79BsXV7QUSfxknpiDmv7/ttUsN4fWUgad6a/UtsrBUsX XCoBNXFyycMuoMRSD06KWreNnwKVCMR3W/r6RlXZ1GfWncwPOGopRDkMSK0o5YIM9G gnpO9xVr8abjUJ/ZGs0zzlpjqGKhkKfQcwntaNjKcpkbcSocGDRXg9p5A5qSd3TG0z 2h296WgEFn61UjJsbXjVhZisR40eKl9QnTWtQkR7mfoj501aHktOkxfJnmDMosrPDz RmwnzyCdkCQBm5cYtJjDglUa6wFR1Y0lVbYpcC08WGEzTQuwlLl263nE4uSGgQsdLQ RY0V2Fh8ipQcA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 53144 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-NcbWOD66Ig+udZ2IPxBH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.=C2=A0 Usually, in these ca= ses > > 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 >=3D 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 =E2=80=98intended for distribution=E2=80=99: I'll look for a forum po= st 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 =E2=80=98yes=E2= =80=99), quoting their response? > > +@c Currently it's always checked out from git, but in principle > > +@c tarballs could be used. > > + > > +Even though the source code is often checked out from version > > control, > > +it is not necessary to use @code{git-version} or @code{hg-version}: > > the > > +releases on ContentDB are formal releases; in fact they are > > upstream's > > +official source of Minetest packages and they are not mutated in- > > place. > > + > > +@c Example (zip): mods by TenPlus1 > > +@c Example (git): basic_materials, ethereal > > +While ContentDB provides the source code of packages in zip form, it > > is > > +recommended not to use these, because users can and do delete old > > +versions.=C2=A0 Likewise, sometimes the maintainer initially did tag > > versions > > +but later stops doing so, breaking @command{guix refresh -u}.=C2=A0 As > > such, > > +it is recommended not to use git tags in @code{origin} records and > > +instead refer to the commit directly. > This combination of version+commit is something I'd generally > discourage (my reasoning for doing so already explained elsewhere), so > to me it might make sense to still explicitly point attention to it.=20 That discussion I had in mind while writing this documentation. 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 =E2=80=98tricking peer review=E2=80=99 issu= es with this though, hence neutral. (See if interested) Hence, adding something like =E2=80=98This is specific to Minetest packages= , for other packages it is advised to use git tags, see [...]=E2=80=99 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. 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 =E2=80=98There 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.=E2=80=99 (*) (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. > 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. 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? > 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 =E2=80=98I'd want a comment like the ones I find in minetest.scm to [...]=E2=80=99 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. Unrelated: git mirrors seem a cool idea! Greetings, Maxime --=-NcbWOD66Ig+udZ2IPxBH 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+4iGRcl7gUCYdtv4RccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7j0EAP4l+FUStGC04kF1e8H6O314BOiR 68HMalqlPX0EyUVVagD+N7CVX0PkQnVvj/F097UPVNc35+pv1aZnS+sLp2ZbjAY= =FxaW -----END PGP SIGNATURE----- --=-NcbWOD66Ig+udZ2IPxBH--