Hello, On Wed 24 Dec 2025 at 07:11am +01, Lucas Nussbaum wrote:
> 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. Thanks, Lucas. All this discussion prompted me to look at policy.git and I saw that there were a bunch of unreleased changes that should be pushed out. I thought that the Priority field becoming optional was the more important thing, actually. Once a change is committed to policy.git it's basically already official, and that happened weeks ago. > 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. Interesting. I would be interested to read the results of a survey like that. -- Sean Whitton
signature.asc
Description: PGP signature
