Hi all, thank you, Russ, for summarizing the discussion so far. As far as it represents the tag2upload proponents point of view, I think it is a fair summary of what was said so far. A few aspects seem to be missing from my point of view, so I'd like to share my own opinion (I don't know whether it qualifies as a reasonable complement to Russ's summary).
Russ's summary seems to miss the questions Paul R. Tagliamonte raised in [1] and extending on in [2]. In essence, what do we consider as source after all? [1.] https://lists.debian.org/debian-vote/2024/06/msg00363.html [2.] https://lists.debian.org/debian-vote/2024/06/msg00424.html The discussion that happened around these questions resonated very well with me because in my point of view tag2upload is aiming at nothing less than a (maybe long due) paradign shift. I'll outline in the next two paragraphs what that paradigm shift is. In general our traditional approach of handling source packages is, we upload upstream's source achive plus our modifications (patches) and instructions how to build it (the packaging). Our tooling (basically dpkg-source) reference all these from a Debian source control file, the .dsc file. The content we distribute within the archive is basically the aggregate of all such uploaded contributions of all Debian developers. We do all of this in the open, i.e. we even distribute the GPG-signed .dsc files so that everyone is able to verify source integrity and which individual Debian developer uploaded the source -- even if the archive infrastructure itself was untrustworthy. From what I understood so far, the overall promise tag2upload tries to make is to simplify package maintenance to an extent that we offload the separation of the patches and the packaging from the upstream source to Git. Once we consider the code/packaging ready for distribution as binary packages to end users, a simple GPG-signed Git tag is sufficient to start all the admirable machinery that in the end provides binary Debian packages end users can install using their package manager. The GPG-signed Git tag allows everyone to verify integrity and authorship of a given Git tree, leading to binary packages. In the tag2upload concept, the uploaded files referenced by the .dsc file and the .dsc file itself are implicitly considered a second class citizen of the Debian ecosystem -- a technical necessity anonymously signed by some tag2upload service. I for one are not convinced yet that we really have to and should sacrifice the current verifyability down to the individual Debian developers, just because we want to work with Git directly. We shouldn't have to give up on some distributed nature of end-to-end verifyability within the supply chain from source code to Debian binary packages. The FTP masters disapprove the current approach, apparently based on similar arguments, merely framed in the context of authorization and integrity checking logic. Yet, the FTP masters seem to rather support the general idea and would like to see an approach where dak and our tools like dpkg-source are directly working with the GPG-signed Git tags. Some questions Ansgar and Joerg raised are pointing in that direction (see [3], [4], [5], [6], [7]). [3.] https://lists.debian.org/debian-vote/2024/06/msg00008.html [4.] https://lists.debian.org/debian-vote/2024/06/msg00371.html [5.] https://lists.debian.org/debian-vote/2024/06/msg00220.html [6.] https://lists.debian.org/debian-vote/2024/06/msg00366.html [7.] https://lists.debian.org/debian-vote/2024/06/msg00402.html In my perception the tag2upload proponents strive to support all kinds of Git workflows. This carries quite some complexity, and all this just for the sake of generating the .dsc file for uploading, partially from more than just one Git commit. If we want to support maintaining Debian packages using pure Git, let's embrace that paradigm shift entirely. Assuming dpkg-source could eventually directly extract (e.g. git pull) the source as needed for building from a Git tag, do we really need all that complexity? Still the tag2upload proponents dismiss a suggestion to also take changing the source format or tooling into account as an unfeasible "boil-the-ocean approach" (see [8]). [8.] https://lists.debian.org/debian-vote/2024/06/msg00446.html Also, shouldn't a supposedly superior maintenance approach be able to attract substantial adoption just by convincing package maintainers with the convenience of use and features, even if it requires potentially intrusive packaging changes like changing source formats? Debhelper seems to have successfully followed such a path in the past. Why shouldn't it work here too? With the available information today, FTP master's pushback arguments seem to be backed well by the delegation. Given their willingness to find a solution, overruling their decision by a GR seems to be rather disproportionate. Kind regards, Micha
