Hi, On 23/12/25 at 11:41 -0800, Otto Kekäläinen wrote: > Hi, > > > For reference the debian-policy bug that discusses Git-Tag-Info and > > Git-Tag-Tagger is #1091868, and the latest version of the patch is > > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1091868;filename=v4-0001-Document-Git-Tag-Tagger-and-Git-Tag-Info-fields.patch;msg=85 > > Also note that this was added to the policy in > https://salsa.debian.org/dbnpolicy/policy/-/commit/bb22500a28c3fca96847ebe81d7f151066f6c41b > by Sean himself 6 months ago, and he rushed to publish it today > immediately after writing the message stating that only tag2upload is > allowed to use this field "because policy says" without mentioning > that he actually wrote the policy and published it today. Yes, one > other person seconded it so Sean and Ian didn't dictate it fully on > their own, but still I find this style of argumentation intellectually > dishonest and I felt the need to highlight this to avoid the audience > from being misled.
I don't think that's a fair characterization of what happened around Git-Tag-*. If we are looking for people to blame, we should blame people like me who now think it's a good idea to generalize the scope of those fields outside of the tag2upload context, but did not follow the tag2upload discussions closely enough to raise that point when it was a good time to do it. The discussion about generalizing those fields could move into a debian-policy bug. However, it might be worth experimenting a bit to understand if it's really useful. One could build a git->dsc audit service by doing: - for a given dsc, use the Vcs-Git field and clone the repository - identify the relevant tag for the version to check (using debian/gbp.conf's debian-tag option if it exists) - build the source - compare with what is in the archive I wonder how many packages could already be checked like that, and how many more an additional dsc field would add. Lucas
