Hi Ian, Am 23.06.24 um 20:32 schrieb Ian Jackson:
Micha Lenk writes ("Re: Summary of the current state of the tag2upload discussion"):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.This is the "Debian source packages in 1993" slide from my 2023 talk. This was true, once. Nowadays, for most packages, this is a pretence. Most people maintain their packages in git. Many upstreams regard git as canonical, and publish tarballs not at all, or only as a concession. The proportion of software for which this is true is steadily rising. Many teams (including of serious, important and longstanding packages) work only in git. The Debian Xen team take upstream signed git tags as their input and work entirely in git.
Yet our tooling and official workflows don't work that way. And when describing the current state, I definitely didn't and do not intend to say that it should stay like that. I hope that was clear from later parts of my mail anyways.
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.I don't think this is the right way to look at it. tag2upload formalises and standardises and streamlines the *existing* git-based workflows which are in use in Debian today.
Okay, but couldn't the existing git-based workflows get formalized and standardized without changing the way how you upload to Debian? Why is it so important to tie the support for so many workflows to the method how the upload is done?
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 ecosystemThe tag2upload system is part of a *parallel* git-based system for handling source code. The intent is that all source packages will be available *both* ways (and can be edited using *both* views).
Yes, this I understood, and that property makes it definitely useful to most developers from the start. It must have been a lot of work to get this far.
What I am trying to do is put git on the same footing as .dscs: you'll be able to use both, with the same level of fidelity and officialness.
... which deserves my full support. Thank you!
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]).People have been thinking about changing source formats, or making other kinds of more radical changes, for many many years. Certainly since at least 2013, when Joey Hess and I and some others we came up with a plan to improve things that we thought would be workable and deployable, unlike the attempts (and suggestions) that had been made so far. We've come a long way already, and significantly improved some maintainers' workflows.
It is possible that I don't have all the needed background here. Would you mind to share a few pointers that outline how these plans worked out? I am genuinely interested in anything that could explain to me why any previous attempts of making Git a first class citizen in the Debian ecosystem didn't succeed so far. This could help me to get a better understanding of your long way, and maybe shed some light on why you're insisting so starkly on some of the tag2upload design decisions.
Cheers, Micha