Hi Ian, There are so many Cambridge debating society tricks in your response I don't know where to start :)
You suggest that there is no need for .dsc files anymore, and that there is no need for upstream orig tarballs anymore, completely ignoring very obvious facts about why we still have them today. Debian is actually one of the few distros that is attempting to have workflows based on importing upstream git repos. Debian currently has two competing popular systems for doing this: git-buildpackage and dgit. Git-buildpackage supports all possible package formats and upstreams, it can be used to follow the DEP-14 layout, and it nicely integrates into Salsa and it's workflows like Merge Requests and CI. Git-buildpackage however has way too many options on how to use it, and the defaults are not ideal and the ability to do dual upstream git and tarball imports with it is not widely known. Your dgit has an architecture where dgit is the gateway to upload and download a git repo representation of Debian packages, but anyone wanting to collaborate on packaging needs a secondary repo hosted on Salsa so that MRs and CI is possible. Yes, we also have some other practices, there is at least one large monorepo too, but claiming that everything is just a soup of whatever seems like a tactic to discredit all existing end-to-end working solutions. Many people share the vision of eventually having everything in git, and maybe in some years we might get there. But we can't do it by wishful thinking or argumenting in a way that tries to twist reality into something that it is not. For example the entire reproducible build infra depends on source packages and does not fetch stuff directly from git. The fact that currently about 8% of the orig tarballs in Debian unstable can't be proven to match 1:1 the upstream tarballs and is in need of a manual review I think severely undermines reproducible builds. I am sure you are aware of this kind of things, yet you write as if it does not exist in your reality. .. > > Yes, using tag2upload will prevent git and archive contents from > > diverging. Hopefully tag2upload also adds support for upstream tags > > and pristine-tar so signed tags and detached signatures can be > > uploaded to Debian (#1110269, #1106071), > > Note that tag2upload doesn't make anything worse, with respect to > upstream git tags. I know people who push to dgit directly and avoid using tag2upload because of the lack of support for pristine-tar and detached signatures in tag2upload. Not having these industry standard security features is clearly making things worse compared to pushing directly with dgit or to uploading dsc files. ... > But nothing about adopting tag2upload makes this situation any worse. > Indeed, it makes it better, because a tag2upload DEP-14 please-upload > tag contains the git objectid of the upstream tag. So with tag2upload > you can *more easily* trace things back to the signed upstream tag. Sure you can and explained already in an earlier email that this is possible. One can always also just download all sources, unpack them and run diff to compare every file to find mismatches. But having to resort to this for every single package, even then upstream does do signatures of some sort, is "making things worse". We also have cases where upstream has gone away fully or partially, and there is no upstream source to download, and checking a signature to the last known valid key of the upstream might be the only data point for an auditor to use. Also, may I remind readers here that the whole thread started from a wish to have the git commit id object and tree recorded somewhere along the metadata. Stuart, the only "independent" person who voted for the policy change (alongside tag2upload authors Sean and Ian) to have `Git-Tag-Info` suggested it could be used, and now it seems that the conclusion here somehow is that other tools shouldn't be allowed to use it, and we didn't really make any progress on improving the git2dcs audit trail..
