GNU logs - #53163, boring messages

Message sent to liliana.prikler@HIDDEN, guix-patches@HIDDEN:

Subject: [bug#53163] [PATCH] doc: Document some reasons for/against git tags/commits.
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: liliana.prikler@HIDDEN, guix-patches@HIDDEN
Resent-Date: Mon, 10 Jan 2022 16:17:03 +0000
Resent-Message-ID: <handler.53163.B.16418313698510 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 53163 <at> debbugs.gnu.org
Cc: liliana.prikler@HIDDEN
Message-ID: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-Q3X5+vJe9UxTJS5diAwO"
Date: Mon, 10 Jan 2022 15:27:55 +0000
MIME-Version: 1.0
User-Agent: Evolution 3.38.3-1 
Received-SPF: pass client-ip=2a02:1800:110:4::f00:18;
 envelope-from=maximedevos@HIDDEN; helo=michel.telenet-ops.be
X-Spam_score_int: -9
X-Spam_score: -1.0
X-Spam_bar: -
X-Spam_report: (-1.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,
 FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--=-Q3X5+vJe9UxTJS5diAwO
Content-Type: multipart/mixed; boundary="=-IewTQoG2qoeFJT+CWoPV"

--=-IewTQoG2qoeFJT+CWoPV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

X-Debbugs-CC: liliana.prikler@HIDDEN

Hi,

For <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D53144#53>,
I'd like to be able to reference some section (not specialised
for Minetest packages, instead more general) explaining when
and when not to use git tags/commits.

I'm not familiar with "git describe", so the documentation
doesn't tell when to use "git describe"-style
tag-number of commits-commit strings.

Greetings,
Maxime.

--=-IewTQoG2qoeFJT+CWoPV
Content-Disposition: attachment;
	filename*0=0001-doc-Document-some-reasons-for-against-git-tags-commi.pat;
	filename*1=ch
Content-Transfer-Encoding: base64
Content-Type: text/x-patch;
	name="0001-doc-Document-some-reasons-for-against-git-tags-commi.patch";
	charset="UTF-8"

RnJvbSA0NjBjMjU4NDIyMDQ5MzZlYWY4ZWFkM2FiMzcwNDllNGI5M2NmMDg2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXhpbWUgRGV2b3MgPG1heGltZWRldm9zQHRlbGVuZXQuYmU+
CkRhdGU6IE1vbiwgMTAgSmFuIDIwMjIgMTU6MTU6MzQgKzAxMDAKU3ViamVjdDogW1BBVENIXSBk
b2M6IERvY3VtZW50IHNvbWUgcmVhc29ucyBmb3IvYWdhaW5zdCBnaXQgdGFncy9jb21taXRzLgoK
KiBkb2MvZ3VpeC50ZXhpIChvcmlnaW4gUmVmZXJlbmNlKTogRG9jdW1lbnQgc29tZSBwb2ludHMg
dG8gY29uc2lkZXIgd2hlbgogIGNob29zaW5nIGJldHdlZW4gY29tbWl0cyBhbmQgdGFncyBpbiAn
Z2l0LXJlZmVyZW5jZScuCi0tLQogZG9jL2d1aXgudGV4aSB8IDE5ICsrKysrKysrKysrKysrKysr
Ky0KIDEgZmlsZSBjaGFuZ2VkLCAxOCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZm
IC0tZ2l0IGEvZG9jL2d1aXgudGV4aSBiL2RvYy9ndWl4LnRleGkKaW5kZXggNThjY2M3NWNjZi4u
NWM1MWRjMTM2MSAxMDA2NDQKLS0tIGEvZG9jL2d1aXgudGV4aQorKysgYi9kb2MvZ3VpeC50ZXhp
CkBAIC03NTE0LDcgKzc1MTQsMjQgQEAgVGhlIFVSTCBvZiB0aGUgR2l0IHJlcG9zaXRvcnkgdG8g
Y2xvbmUuCiBUaGlzIHN0cmluZyBkZW5vdGVzIGVpdGhlciB0aGUgY29tbWl0IHRvIGZldGNoIChh
IGhleGFkZWNpbWFsIHN0cmluZyksCiBvciB0aGUgdGFnIHRvIGZldGNoLiAgWW91IGNhbiBhbHNv
IHVzZSBhIGBgc2hvcnQnJyBjb21taXQgSUQgb3IgYQogQGNvbW1hbmR7Z2l0IGRlc2NyaWJlfSBz
dHlsZSBpZGVudGlmaWVyIHN1Y2ggYXMKLUBjb2Rle3YxLjAuMS0xMC1nNThkNzkwOWM5N30uCitA
Y29kZXt2MS4wLjEtMTAtZzU4ZDc5MDljOTd9LiAgT2Z0ZW4sIHRoZXJlIGlzIG5vIGNsZWFyLWN1
dCBhbnN3ZXIgdG8KK3RoZSBxdWVzdGlvbiB3aGV0aGVyIGEgY29tbWl0IG9yIHRhZyBzaG91bGQg
YmUgdXNlZC4gIEhvd2V2ZXIsIHRoZXJlIGFyZQorc29tZSBwb2ludHMgdG8gY29uc2lkZXI6CisK
K0lmIHVwc3RyZWFtIHJlbW92ZXMgb2xkIHRhZ3Mgb3IgbXV0YXRlcyBleGlzdGluZyB0YWdzIGlu
LXBsYWNlLCB0aGVuIGEKK2NvbW1pdCBzaG91bGQgYmUgdXNlZCB0byBhdm9pZCBmdXR1cmUgYnJl
YWthZ2UuICBTb21ldGltZXMgdXBzdHJlYW0gZG9lcworbm90IHRhZyByZWxlYXNlcyBhdCBhbGws
IGluIHRoaXMgY2FzZSBjb21taXRzIGFyZSB1bmF2b2lkYWJsZS4gIEluIGEKK3ZlcnkgZmV3IGNh
c2VzIChAcHhyZWZ7VmVyc2lvbiBOdW1iZXJzfSksIEd1aXggaW50ZW50aW9uYWxseSB1c2VzIGEK
K2NvbW1pdCB0aGF0IGRvZXMgbm90IGNvcnJlc3BvbmQgdG8gYSByZWxlYXNlLCBpbiB3aGljaCBj
YXNlIGEgY29tbWl0CitpcyByZXF1aXJlZC4KKworU29tZSBHaXQgcmVwb3NpdG9yaWVzIG9ubHkg
YWxsb3cgY2hlY2tpbmcgb3V0IHRhZ3MgZGlyZWN0bHkgYW5kIHJlcXVpcmUKK2Nsb25pbmcgdGhl
IGVudGlyZSBHaXQgcmVwb3NpdG9yeSB0byBjaGVja291dCBhIHNpbmdsZSBjb21taXQ7IHVzaW5n
IGEKK3RhZyB3b3VsZCByZWR1Y2UgbmV0d29yayB0cmFmZmljIGluIHRoZXNlIGNhc2VzLiBUaGlz
IGRvZXMgbm90IGFwcGVhciB0bworYmUgYSBzaWduaWZpY2FudCBwcm9ibGVtIGluIHByYWN0aWNl
LCB0aG91Z2guCisKK0NvbW1pdHMgbWFrZSByZXZpZXdpbmcgc29tZXdoYXQgdHJpY2tpZXIsIGJl
Y2F1c2UgdGhlIHJldmlld2VyIGhhcyB0bwordmVyaWZ5IHRoYXQgdGhhdCB0aGUgY29tbWl0IGFj
dHVhbGx5IGNvcnJlc3BvbmRzIHRvIHRoZSBwYWNrYWdlIHZlcnNpb24uCiAKIEBpdGVtIEBjb2Rl
e3JlY3Vyc2l2ZT99IChkZWZhdWx0OiBAY29kZXsjZn0pCiBUaGlzIEJvb2xlYW4gaW5kaWNhdGVz
IHdoZXRoZXIgdG8gcmVjdXJzaXZlbHkgZmV0Y2ggR2l0IHN1Yi1tb2R1bGVzLgoKYmFzZS1jb21t
aXQ6IDlmZDRmNGIwOWNjMDQ5NWQ2YjE0MThmMTcxZmY3MzhhMTA4NmNjMDAKcHJlcmVxdWlzaXRl
LXBhdGNoLWlkOiA5ZTA3MDgxOTA5NmE1YjNkZjIyMDcwNjg2NmRlM2Y5YTI0NzAwYWRkCnByZXJl
cXVpc2l0ZS1wYXRjaC1pZDogOWUwODFjYWY2ZGYxZTliN2ZhNGVjZjBlODE2MDg5Y2I2NTg5N2Q3
YgpwcmVyZXF1aXNpdGUtcGF0Y2gtaWQ6IDhmYTE0Y2IyZDFmY2M0YjRkNWJlMjI3YmY4YTI2OTFh
OTEyNTAwYzAKcHJlcmVxdWlzaXRlLXBhdGNoLWlkOiAzZDRiZjJjYmQzNmUyOWEwMzFjNmNjZDEz
ZmRmNGVkZDUxYjY3NjUyCnByZXJlcXVpc2l0ZS1wYXRjaC1pZDogYjc0MDkxMWIyZmFiNmU4N2Yw
MDNlMTNjZTIxZDNjNzI2ZDdmZmViNgpwcmVyZXF1aXNpdGUtcGF0Y2gtaWQ6IDI0OTVlMTJkMGVm
YmY0MmZlODQ3ZTc0MTFhOWM3YWJiZjZiMDljMzgKcHJlcmVxdWlzaXRlLXBhdGNoLWlkOiBmMjgx
MjMxZDk2MDU5MTc5YjZiODkxZDk5OWRkYTc5OGIwOTllMmZiCnByZXJlcXVpc2l0ZS1wYXRjaC1p
ZDogYzYwYjMzMGY5NjcyMWRhMWY3NzkwZGQyOWI1ZDQyOGUzMTJlN2IyZQpwcmVyZXF1aXNpdGUt
cGF0Y2gtaWQ6IGEzYWI1NWVhZjBkZWNlNTg2YzUxM2ZhNTY3MTQxNGZmOTAyZWIxY2QKcHJlcmVx
dWlzaXRlLXBhdGNoLWlkOiBmZjQ3ZWQwMDg2ODM3ZjE4MjkzZDY3ZTVlZGQwMWNhMTRjNmY4NGM5
CnByZXJlcXVpc2l0ZS1wYXRjaC1pZDogMmM4MDVmNDBjMzdmZWQzZWI4ZTY5NDU2ZDRjOTBjMGE3
NWI2NDNiZQpwcmVyZXF1aXNpdGUtcGF0Y2gtaWQ6IGRmYzk1MzQzMDdmZDQzNjUyMDViY2QyMmNl
YTU3YzNlMTk2YjI5ZTgKcHJlcmVxdWlzaXRlLXBhdGNoLWlkOiA1MDM1ZDc1ZjY0NjNkYmNjOGQ3
ZTI5NzgyYmE5YjFmN2E1ODY3YzQyCi0tIAoyLjMwLjIKCg==

--=-IewTQoG2qoeFJT+CWoPV--

--=-Q3X5+vJe9UxTJS5diAwO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYdxQdBccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7o53AP43+6G6YdJ705hmz611HxrMvePD
rODF366NzYuD6kZeTgD/aN5uu0I0357cp9WrEhAr04xa2d8G8Pgtu75aNr5hNw4=
=5kAN
-----END PGP SIGNATURE-----

--=-Q3X5+vJe9UxTJS5diAwO--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Maxime Devos <maximedevos@HIDDEN>
Subject: bug#53163: Acknowledgement ([PATCH] doc: Document some reasons
 for/against git tags/commits.)
Message-ID: <handler.53163.B.16418313698510.ack <at> debbugs.gnu.org>
References: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
X-Gnu-PR-Message: ack 53163
X-Gnu-PR-Package: guix-patches
X-Gnu-PR-Keywords: patch
Reply-To: 53163 <at> debbugs.gnu.org
Date: Mon, 10 Jan 2022 16:17:03 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  liliana.prikler@HIDDEN
(after having been given a bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 guix-patches@HIDDEN

If you wish to submit further information on this problem, please
send it to 53163 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
53163: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D53163
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to guix-patches@HIDDEN:

Subject: [bug#53163] [PATCH] doc: Document some reasons for/against git tags/commits.
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 10 Jan 2022 19:44:01 +0000
Resent-Message-ID: <handler.53163.B53163.164184381229837 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Maxime Devos <maximedevos@HIDDEN>, 53163 <at> debbugs.gnu.org
Message-ID: <3aeda438471930ca3b958a35681a8191cc51fe92.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Mon, 10 Jan 2022 20:43:22 +0100
In-Reply-To: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
References: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi,

Am Montag, dem 10.01.2022 um 15:27 +0000 schrieb Maxime Devos:
> For <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53144#53>,
> I'd like to be able to reference some section (not specialised
> for Minetest packages, instead more general) explaining when
> and when not to use git tags/commits.
Generally LGTM.

> +not tag releases at all, in this case commits are unavoidable.  In a
> +very few cases (@pxref{Version Numbers}), Guix intentionally uses a
"In a very few cases" looks like a typo.  "In few cases" or "In some
exceptional cases" would work well.

> +Commits make reviewing somewhat trickier, because the reviewer has
> to
> +verify that that the commit actually corresponds to the package
> version.
I'd also add a line regarding the difficulty to verify that a commit
did once belong to a tag as a future reader, but I'm not sure what
exactly to advise here and how.  In the particular case of minetest, we
have an external map of "tags" to commits that can be queried, but for
most repos I fear the tags would simply be lost to time.

> I'm not familiar with "git describe", so the documentation
> doesn't tell when to use "git describe"-style
> tag-number of commits-commit strings.
That's a general question that has not reached a conclusion yet.  IIRC
the goal was to make tags more robust by replacing them with git-
describe like tags.  This would also make it easier to port between
revisioned commit and tagged one, since one would have to let-bind
commit either way.

Cheers

Message sent to guix-patches@HIDDEN:

Subject: [bug#53163] [PATCH] doc: Document some reasons for/against git tags/commits.
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 10 Jan 2022 21:10:02 +0000
Resent-Message-ID: <handler.53163.B53163.16418489426014 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 53163 <at> debbugs.gnu.org
Message-ID: <61f01b2b439db750424023bb2555865ff8139255.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
Date: Mon, 10 Jan 2022 22:08:45 +0100
In-Reply-To: <3aeda438471930ca3b958a35681a8191cc51fe92.camel@HIDDEN>
References: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
 <3aeda438471930ca3b958a35681a8191cc51fe92.camel@HIDDEN>
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-E9/ZsKMecsQpDaKGoiYg"
User-Agent: Evolution 3.38.3-1 
MIME-Version: 1.0
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>


--=-E9/ZsKMecsQpDaKGoiYg
Content-Type: multipart/mixed; boundary="=-9tWkZ+U6l8zv3bNu75JU"


--=-9tWkZ+U6l8zv3bNu75JU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

A v2 patch with the suggestions applied is attached.

Liliana Marie Prikler schreef op ma 10-01-2022 om 20:43 [+0100]:
> Hi,
>=20
> Am Montag, dem 10.01.2022 um 15:27 +0000 schrieb Maxime Devos:
> > For <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D53144#53>,
> > I'd like to be able to reference some section (not specialised
> > for Minetest packages, instead more general) explaining when
> > and when not to use git tags/commits.
> Generally LGTM.
>=20
> > +not tag releases at all, in this case commits are unavoidable.  In a
> > +very few cases (@pxref{Version Numbers}), Guix intentionally uses a
> "In a very few cases" looks like a typo.  "In few cases" or "In some
> exceptional cases" would work well.

=E2=80=98In some exceptional cases=E2=80=99 looks better to me, applied.

> > +Commits make reviewing somewhat trickier, because the reviewer has
> > to
> > +verify that that the commit actually corresponds to the package
> > version.
> I'd also add a line regarding the difficulty to verify that a commit
> did once belong to a tag as a future reader, but I'm not sure what
> exactly to advise here and how.
>=20

Done:=20
=E2=80=98Likewise, commits make it more difficult for a future reader to ve=
rify
that a commit did once correspond to a version tag=E2=80=99.

>   In the particular case of minetest, we
> have an external map of "tags" to commits that can be queried, but for
> most repos I fear the tags would simply be lost to time.

Here "tags" =3D releases on content.minetest.net, and not Git tags?

> > I'm not familiar with "git describe", so the documentation
> > doesn't tell when to use "git describe"-style
> > tag-number of commits-commit strings.
> That's a general question that has not reached a conclusion yet.  IIRC
> the goal was to make tags more robust by replacing them with git-
> describe like tags.  This would also make it easier to port between
> revisioned commit and tagged one, since one would have to let-bind
> commit either way.

FWIW,
the git updater in (guix upstream) might need to be modified to
support the "git describe" style in commit fields,=C2=A0and a linter
to verify that the tag+number corresponds to the commit (to
avoid some =E2=80=98tricking peer review=E2=80=99 issues), but otherwise th=
is
seems rather nice to me.  I didn't investigate closely though.

Greetings,
Maxime.

--=-9tWkZ+U6l8zv3bNu75JU
Content-Description: 
Content-Disposition: inline;
	filename*0=v2-0001-doc-Document-some-reasons-for-against-git-tags-co.pat;
	filename*1=ch
Content-Type: text/x-patch;
	name="v2-0001-doc-Document-some-reasons-for-against-git-tags-co.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

RnJvbSAyODg3ZmE0MThhNmYwOTdkN2MwNzM4MGFiNmZmNmY5NDUyMDA4MDczIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXhpbWUgRGV2b3MgPG1heGltZWRldm9zQHRlbGVuZXQuYmU+
CkRhdGU6IE1vbiwgMTAgSmFuIDIwMjIgMTU6MTU6MzQgKzAxMDAKU3ViamVjdDogW1BBVENIIHYy
XSBkb2M6IERvY3VtZW50IHNvbWUgcmVhc29ucyBmb3IvYWdhaW5zdCBnaXQgdGFncy9jb21taXRz
LgoKKiBkb2MvZ3VpeC50ZXhpIChvcmlnaW4gUmVmZXJlbmNlKTogRG9jdW1lbnQgc29tZSBwb2lu
dHMgdG8gY29uc2lkZXIgd2hlbgogIGNob29zaW5nIGJldHdlZW4gY29tbWl0cyBhbmQgdGFncyBp
biAnZ2l0LXJlZmVyZW5jZScuCi0tLQogZG9jL2d1aXgudGV4aSB8IDIxICsrKysrKysrKysrKysr
KysrKysrLQogMSBmaWxlIGNoYW5nZWQsIDIwIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkK
CmRpZmYgLS1naXQgYS9kb2MvZ3VpeC50ZXhpIGIvZG9jL2d1aXgudGV4aQppbmRleCA1OGNjYzc1
Y2NmLi4yMDE5MmQ5ZTk5IDEwMDY0NAotLS0gYS9kb2MvZ3VpeC50ZXhpCisrKyBiL2RvYy9ndWl4
LnRleGkKQEAgLTc1MTQsNyArNzUxNCwyNiBAQCBUaGUgVVJMIG9mIHRoZSBHaXQgcmVwb3NpdG9y
eSB0byBjbG9uZS4KIFRoaXMgc3RyaW5nIGRlbm90ZXMgZWl0aGVyIHRoZSBjb21taXQgdG8gZmV0
Y2ggKGEgaGV4YWRlY2ltYWwgc3RyaW5nKSwKIG9yIHRoZSB0YWcgdG8gZmV0Y2guICBZb3UgY2Fu
IGFsc28gdXNlIGEgYGBzaG9ydCcnIGNvbW1pdCBJRCBvciBhCiBAY29tbWFuZHtnaXQgZGVzY3Jp
YmV9IHN0eWxlIGlkZW50aWZpZXIgc3VjaCBhcwotQGNvZGV7djEuMC4xLTEwLWc1OGQ3OTA5Yzk3
fS4KK0Bjb2Rle3YxLjAuMS0xMC1nNThkNzkwOWM5N30uICBPZnRlbiwgdGhlcmUgaXMgbm8gY2xl
YXItY3V0IGFuc3dlciB0bwordGhlIHF1ZXN0aW9uIHdoZXRoZXIgYSBjb21taXQgb3IgdGFnIHNo
b3VsZCBiZSB1c2VkLiAgSG93ZXZlciwgdGhlcmUgYXJlCitzb21lIHBvaW50cyB0byBjb25zaWRl
cjoKKworSWYgdXBzdHJlYW0gcmVtb3ZlcyBvbGQgdGFncyBvciBtdXRhdGVzIGV4aXN0aW5nIHRh
Z3MgaW4tcGxhY2UsIHRoZW4gYQorY29tbWl0IHNob3VsZCBiZSB1c2VkIHRvIGF2b2lkIGZ1dHVy
ZSBicmVha2FnZS4gIFNvbWV0aW1lcyB1cHN0cmVhbSBkb2VzCitub3QgdGFnIHJlbGVhc2VzIGF0
IGFsbCwgaW4gdGhpcyBjYXNlIGNvbW1pdHMgYXJlIHVuYXZvaWRhYmxlLiAgSW4gc29tZQorZXhj
ZXB0aW9uYWwgY2FzZXMgKEBweHJlZntWZXJzaW9uIE51bWJlcnN9KSwgR3VpeCBpbnRlbnRpb25h
bGx5IHVzZXMgYQorY29tbWl0IHRoYXQgZG9lcyBub3QgY29ycmVzcG9uZCB0byBhIHJlbGVhc2Us
IGluIHdoaWNoIGNhc2UgYSBjb21taXQgaXMKK3JlcXVpcmVkLgorCitTb21lIEdpdCByZXBvc2l0
b3JpZXMgb25seSBhbGxvdyBjaGVja2luZyBvdXQgdGFncyBkaXJlY3RseSBhbmQgcmVxdWlyZQor
Y2xvbmluZyB0aGUgZW50aXJlIEdpdCByZXBvc2l0b3J5IHRvIGNoZWNrb3V0IGEgc2luZ2xlIGNv
bW1pdDsgdXNpbmcgYQordGFnIHdvdWxkIHJlZHVjZSBuZXR3b3JrIHRyYWZmaWMgaW4gdGhlc2Ug
Y2FzZXMuIFRoaXMgZG9lcyBub3QgYXBwZWFyIHRvCitiZSBhIHNpZ25pZmljYW50IHByb2JsZW0g
aW4gcHJhY3RpY2UsIHRob3VnaC4KKworQ29tbWl0cyBtYWtlIHJldmlld2luZyBzb21ld2hhdCB0
cmlja2llciwgYmVjYXVzZSB0aGUgcmV2aWV3ZXIgaGFzIHRvCit2ZXJpZnkgdGhhdCB0aGF0IHRo
ZSBjb21taXQgYWN0dWFsbHkgY29ycmVzcG9uZHMgdG8gdGhlIHBhY2thZ2UgdmVyc2lvbi4KK0xp
a2V3aXNlLCBjb21taXRzIG1ha2UgaXQgbW9yZSBkaWZmaWN1bHQgZm9yIGEgZnV0dXJlIHJlYWRl
ciB0byB2ZXJpZnkKK3RoYXQgYSBjb21taXQgZGlkIG9uY2UgY29ycmVzcG9uZCB0byBhIHZlcnNp
b24gdGFnLgogCiBAaXRlbSBAY29kZXtyZWN1cnNpdmU/fSAoZGVmYXVsdDogQGNvZGV7I2Z9KQog
VGhpcyBCb29sZWFuIGluZGljYXRlcyB3aGV0aGVyIHRvIHJlY3Vyc2l2ZWx5IGZldGNoIEdpdCBz
dWItbW9kdWxlcy4KLS0gCjIuMzAuMgoK


--=-9tWkZ+U6l8zv3bNu75JU--

--=-E9/ZsKMecsQpDaKGoiYg
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+4iGRcl7gUCYdygXRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7gulAP90+QhZVU30KMC/7mAz+AEFtw8C
QcAXWjJsH6tO2MeYhwEAivIdfA6dGPsyNvcQ/6tE7BLuV/2SAMcCfzZy1VudCgU=
=mfxQ
-----END PGP SIGNATURE-----

--=-E9/ZsKMecsQpDaKGoiYg--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#53163] [PATCH] doc: Document some reasons for/against git tags/commits.
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 10 Jan 2022 21:37:02 +0000
Resent-Message-ID: <handler.53163.B53163.16418505848800 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 53163
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxime Devos <maximedevos@HIDDEN>, 53163 <at> debbugs.gnu.org
Received: via spool by 53163-submit <at> debbugs.gnu.org id=B53163.16418505848800
          (code B ref 53163); Mon, 10 Jan 2022 21:37:02 +0000
Received: (at 53163) by debbugs.gnu.org; 10 Jan 2022 21:36:24 +0000
Received: from localhost ([127.0.0.1]:53423 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n72L2-0002Hs-7S
	for submit <at> debbugs.gnu.org; Mon, 10 Jan 2022 16:36:24 -0500
Received: from mail-wr1-f66.google.com ([209.85.221.66]:42998)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1n72L0-0002Hd-4t
 for 53163 <at> debbugs.gnu.org; Mon, 10 Jan 2022 16:36:22 -0500
Received: by mail-wr1-f66.google.com with SMTP id k30so11722114wrd.9
 for <53163 <at> debbugs.gnu.org>; Mon, 10 Jan 2022 13:36:22 -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=DZZbe4w6knvh8k5X5Zu4siXrLQ3T7BMkJu9W1OqGWQc=;
 b=csnwCHPm6Rgsvo2nLcTjE/9vsAaGbFXizpFqjcHbibWT33PM1ARJAQPTjbp+zo4dZo
 uiz2+ZN2oXCicxr7L99hpHrs5VMJAdysSbI4QEWQaPbnLbZDc9IE/d3ahYMSekeBUYeX
 JAqJQNMvO7nFo9UHlfemtuAd1VVIdV02O9C4C6VMrxAQ82PtLAs/dkoe0aMuDQR4ljK5
 hQsQ/OnvR/xpCwcRRZFGmO3EdAilUhBCC27itWhD+m8wITkWNR8GGddgg8m3hzu9tAOI
 +MebWsB8uLAMtEmSsq5g5vZ6QDza9LkBk4JXNDLgwcEIyBYQ7OXYWG9+KRxYD1mMTLSM
 aXmg==
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=DZZbe4w6knvh8k5X5Zu4siXrLQ3T7BMkJu9W1OqGWQc=;
 b=qJS9RJCSYls6pp6Jn0i1ujFdFaMM2qM1F86tDdst99ROJYRHiZNA0xnUqW9/G9vdHZ
 hAl8KlsktpBRCMbX+P3Vw56y/cd1w8bGyjdpf+Hss91R7ToAy+aLXFZf7ZcXPprdgPLl
 EleDVrOFxokWB5rmoWcL3wYWGLUfGDfXKwthwPWpZNVkqeZc7QKDHPf2MLKLY34w8Zba
 FIc9F943aPhWfSMf54nsNn8+LKtMYrB08WipEy+8hTXsC7IMq6ZRWZpbri3zDo6ii91r
 IHjcpop2TPFxfey+qZ4+gcEh0kzRil6Ie6FE2irogaHNwJm1HSxLk9KZnCMmsCiB238+
 D10g==
X-Gm-Message-State: AOAM532cgLaOKvAEEWy+fRFOW1Am2QLcikXYR0EXqW4lZiQdrJYiErOD
 sNAhg3QjVQOb6Al1Xv7ztLU=
X-Google-Smtp-Source: ABdhPJwfqG2gm7paKSunMW+TXAxJR02uuQkczZ6AE9JV1m7IqFrzbALpR51gPVbmj2W2MicmXqNOYw==
X-Received: by 2002:adf:f74f:: with SMTP id z15mr1241904wrp.264.1641850576255; 
 Mon, 10 Jan 2022 13:36:16 -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 l25sm39221wmh.18.2022.01.10.13.36.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Jan 2022 13:36:15 -0800 (PST)
Message-ID: <855630e60e664bb9ad57f1e07479e393b4f8fa06.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Mon, 10 Jan 2022 22:36:14 +0100
In-Reply-To: <61f01b2b439db750424023bb2555865ff8139255.camel@HIDDEN>
References: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
 <3aeda438471930ca3b958a35681a8191cc51fe92.camel@HIDDEN>
 <61f01b2b439db750424023bb2555865ff8139255.camel@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi,

Am Montag, dem 10.01.2022 um 22:08 +0100 schrieb Maxime Devos:
> A v2 patch with the suggestions applied is attached.
LGTM, but let's wait for more opinions.  Since this does concern Guix
as a whole I don't want to be the sole dictator here.

> 
> >   In the particular case of minetest, we
> > have an external map of "tags" to commits that can be queried, but
> > for
> > most repos I fear the tags would simply be lost to time.
> 
> Here "tags" = releases on content.minetest.net, and not Git tags?
Yep, "tags" = contentdb releases, I forgot the terminology here :)
> > 

> > That's a general question that has not reached a conclusion yet. 
> > IIRC the goal was to make tags more robust by replacing them with
> > git-describe like tags.  This would also make it easier to port
> > between revisioned commit and tagged one, since one would have to
> > let-bind commit either way.
> 
> FWIW, the git updater in (guix upstream) might need to be modified to
> support the "git describe" style in commit fields, and a linter
> to verify that the tag+number corresponds to the commit (to
> avoid some ‘tricking peer review’ issues), but otherwise this
> seems rather nice to me.  I didn't investigate closely though.
Yeah, in my opinion we'd also want a (git-tag VERSION COMMIT) procedure
to produce it, which is definitely c-u material.  And obviously long
hashes would be required.

Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#53163] [PATCH] doc: Document some reasons for/against git tags/commits.
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 26 Jan 2022 11:41:02 +0000
Resent-Message-ID: <handler.53163.B53163.164319721616035 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 53163
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxime Devos <maximedevos@HIDDEN>
Cc: liliana.prikler@HIDDEN, 53163 <at> debbugs.gnu.org
Received: via spool by 53163-submit <at> debbugs.gnu.org id=B53163.164319721616035
          (code B ref 53163); Wed, 26 Jan 2022 11:41:02 +0000
Received: (at 53163) by debbugs.gnu.org; 26 Jan 2022 11:40:16 +0000
Received: from localhost ([127.0.0.1]:51092 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nCget-0004AZ-RN
	for submit <at> debbugs.gnu.org; Wed, 26 Jan 2022 06:40:16 -0500
Received: from hera.aquilenet.fr ([185.233.100.1]:36224)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1nCger-0004AE-Ib
 for 53163 <at> debbugs.gnu.org; Wed, 26 Jan 2022 06:40:14 -0500
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id DD1A045B;
 Wed, 26 Jan 2022 12:40:06 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ZTd3xekqMPeq; Wed, 26 Jan 2022 12:40:06 +0100 (CET)
Received: from ribbon (unknown [IPv6:2a01:e0a:1d:7270:af76:b9b:ca24:c465])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id C4343316;
 Wed, 26 Jan 2022 12:40:05 +0100 (CET)
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
References: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
Date: Wed, 26 Jan 2022 12:40:05 +0100
In-Reply-To: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
 (Maxime Devos's message of "Mon, 10 Jan 2022 15:27:55 +0000")
Message-ID: <87czkeiv3e.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spamd-Bar: /
Authentication-Results: hera.aquilenet.fr;
	none
X-Rspamd-Server: hera
X-Rspamd-Queue-Id: DD1A045B
X-Spamd-Result: default: False [-0.10 / 15.00]; ARC_NA(0.00)[];
 RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[];
 RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_ENVRCPT(0.00)[gmail.com];
 TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_RCPT(0.00)[];
 MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[];
 FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+];
 RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[];
 MID_RHS_MATCH_FROM(0.00)[];
 FREEMAIL_CC(0.00)[debbugs.gnu.org,gmail.com]
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hi!

Maxime Devos <maximedevos@HIDDEN> skribis:

> From 460c25842204936eaf8ead3ab37049e4b93cf086 Mon Sep 17 00:00:00 2001
> From: Maxime Devos <maximedevos@HIDDEN>
> Date: Mon, 10 Jan 2022 15:15:34 +0100
> Subject: [PATCH] doc: Document some reasons for/against git tags/commits.
>
> * doc/guix.texi (origin Reference): Document some points to consider when
>   choosing between commits and tags in 'git-reference'.
> ---
>  doc/guix.texi | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 58ccc75ccf..5c51dc1361 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -7514,7 +7514,24 @@ The URL of the Git repository to clone.
>  This string denotes either the commit to fetch (a hexadecimal string),
>  or the tag to fetch.  You can also use a ``short'' commit ID or a
>  @command{git describe} style identifier such as
> -@code{v1.0.1-10-g58d7909c97}.
> +@code{v1.0.1-10-g58d7909c97}.  Often, there is no clear-cut answer to
> +the question whether a commit or tag should be used.  However, there are
> +some points to consider:
> +
> +If upstream removes old tags or mutates existing tags in-place, then a
> +commit should be used to avoid future breakage.  Sometimes upstream does
> +not tag releases at all, in this case commits are unavoidable.  In a
> +very few cases (@pxref{Version Numbers}), Guix intentionally uses a
> +commit that does not correspond to a release, in which case a commit
> +is required.
> +
> +Some Git repositories only allow checking out tags directly and require
> +cloning the entire Git repository to checkout a single commit; using a
> +tag would reduce network traffic in these cases. This does not appear to
> +be a significant problem in practice, though.
> +
> +Commits make reviewing somewhat trickier, because the reviewer has to
> +verify that that the commit actually corresponds to the package version.

I think we should separate reference material from guidelines.  Perhaps
this should rather go under =E2=80=9CPackaging Guidelines=E2=80=9D, next to=
 =E2=80=9CVersion
Numbers=E2=80=9D?

The problem is that it explains the tradeoff but, as you write, does not
provide any answer.  So it=E2=80=99s not strictly speaking a =E2=80=9Cguide=
line=E2=80=9D but may
still be useful to have though.

Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#53163] [PATCH] doc: Document some reasons for/against git tags/commits.
References: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
In-Reply-To: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@HIDDEN>
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 30 Jun 2022 09:36:02 +0000
Resent-Message-ID: <handler.53163.B53163.16565817567661 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 53163
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 53163 <at> debbugs.gnu.org
Received: via spool by 53163-submit <at> debbugs.gnu.org id=B53163.16565817567661
          (code B ref 53163); Thu, 30 Jun 2022 09:36:02 +0000
Received: (at 53163) by debbugs.gnu.org; 30 Jun 2022 09:35:56 +0000
Received: from localhost ([127.0.0.1]:32901 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1o6qaa-0001zV-9a
	for submit <at> debbugs.gnu.org; Thu, 30 Jun 2022 05:35:56 -0400
Received: from andre.telenet-ops.be ([195.130.132.53]:46208)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1o6qaV-0001zG-KD
 for 53163 <at> debbugs.gnu.org; Thu, 30 Jun 2022 05:35:54 -0400
Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be
 ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a])
 by andre.telenet-ops.be with bizsmtp
 id pMbp2700H4UW6Th01MbpqU; Thu, 30 Jun 2022 11:35:50 +0200
Message-ID: <e4132f76e27642f16006d57a40711e3bd2a473c6.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
Date: Thu, 30 Jun 2022 11:35:44 +0200
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-OtfN53BsQXXVuktctijO"
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=1656581750; bh=lXNX6aSKLJi0Vtw2U6DAgDYwP2XxIL9PYh0c7QQC8hc=;
 h=Subject:From:To:Date;
 b=RetpEyN9YhYWeeKVGg4ajTFZ9z9YIfdVyzrIg0BckZ3hzG3TjiIdxKIzh4E3B0mo6
 08IfQSXjlQBahTIVdWSTat6fexG6SIebG80RLMQ4yzoKQ09fQJszxzxXxEK+6JiWYi
 Pqqlx09PtT5/mg86J1HizxyUViRmhwJixZ3By3Es+o2PbJtIH9fgkHQP1tYrSA7Ctc
 pCI9CHilCHWGwvmEDEKAXBT7BZhNgHnV67sc6xJxqQojP1mvErVvr84bilpJYrtH94
 ByU/6HGRTFLoXgaIELlwRHq0XqE+Ra7eAA7JlmbX6X7DmxPBreSr/oSvOdNkT/jowY
 cGRzUc7gJOGPg==
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--=-OtfN53BsQXXVuktctijO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> I think we should separate reference material from guidelines.=20
> Perhaps this should rather go under =E2=80=9CPackaging Guidelines=E2=80=
=9D, next to
> =E2=80=9CVersion Numbers=E2=80=9D?

I suppose for consistency with the =E2=80=98Packaging Guidelines=E2=80=99 c=
hapter, I
could move it there, though I'd like to add a cross-reference to the
description of =E2=80=98commit=E2=80=99 in git-reference for convenience, e=
.g. maybe:

     =E2=80=98commit=E2=80=99
          This string denotes either the commit to fetch (a hexadecimal
          string), or the tag to fetch.  You can also use a =E2=80=9Cshort=
=E2=80=9D
          commit ID or a =E2=80=98git describe=E2=80=99 style identifier su=
ch as
          =E2=80=98v1.0.1-10-g58d7909c97=E2=80=99. =C2=A0**To decide betwee=
n choosing a
          commit or a tag, the guidelines in [cross-reference] may be
          useful.**

?

(At first I'd have preferred to not separate reference material to keep
all information on commits together, but on second thought separating
them would be more orderly and it's not like we don't have cross-
references, so maybe it would be better to split ...)

> Toggle quote (4 lines)
> > +Commits make reviewing somewhat trickier, because the reviewer has
> > +to
> > +verify that that the commit actually corresponds to the package
> > version.
> I'd also add a line regarding the difficulty to verify that a commit
> did once belong to a tag as a future reader, but I'm not sure what
> exactly to advise here and how.  In the particular case of minetest,
> we have an external map of "tags" to commits that can be queried, but
> for most repos I fear the tags would simply be lost to time.

FWIW, the same holds (though maybe to a lesser degree in practice?) for
hashes and tarballs), not specific to git.

Anyway, SWH keeps this historical information, e.g. here are two lists
of tags->commits of the Minetest repo at two different points in time:

* https://archive.softwareheritage.org/browse/snapshot/d063751724753b97de41=
a34aa3d1779186530bb4/releases/?origin_url=3Dhttps://github.com/minetest/min=
etest&timestamp=3D2020-01-18T00:07:33Z
* https://archive.softwareheritage.org/browse/snapshot/81e0233dbaf285922bef=
2281f4e5cbbe5fbc7ea0/releases/?origin_url=3Dhttps://github.com/minetest/min=
etest&timestamp=3D2022-06-25T04:01:20Z

That assumes trusting SWH to be correct of course (and a bit of a
SPOF though I don't expect problems), but with some work, things can
be verified even for repos that delete tags.

Anyway, any remaining comments or a second opinion?  (Would like more
than three people for something like this?)

Greetings,
Maxime.

--=-OtfN53BsQXXVuktctijO
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+4iGRcl7gUCYr1ucBccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7hWbAQDTLe699nkJEK3/jpG9+6Fe0YTn
b1uoxTGZaCm3y8xIiwD/auEMUcbq/Vqvl5zuRRrB136WW/52cYg/EFHLedVZkQ8=
=P2bS
-----END PGP SIGNATURE-----

--=-OtfN53BsQXXVuktctijO--

Last modified: Thu, 30 Jun 2022 09:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.