Louis-Philippe Véronneau <[email protected]> writes: > On 2024-06-16 2 h 23 p.m., Russ Allbery wrote: >> For the existing source package signatures, a simplified sequence looks >> like this: >> human --> (1) dpkg-buildpackage --> (2) debsign --> (3) archive >> For tag2upload, a simplified sequence looks like: >> human --> (1) Git --> (2) tag2upload --> (3) debsign --> (4) >> archive
> Please excuse my naiveté, but how do you actually know that your package > "works" with the tag2upload workflow if you're not building anything > locally before pushing? Jonas is correct that this is a highly simplified picture intended only to highlight the security properties, and I personally will do all sorts of other things locally to verify my work before I decide to upload it. But that's a boring answer; the really interesting answer for the purposes of what tag2upload could accomplish is "Salsa CI." Salsa is already capable of doing a lot of those tests, like running Lintian and autopkgtests, so if you have a good suite of autopkgtests, it can do most of the heavy lifting for you. You can put up a merge request, walk away and have a cup of coffee or work on some other problem, and come back to see if it found any issues. This is a development model used a lot outside of Debian: development consists mostly of reviewing and merging merge requests in a forge, the forge CI takes care of testing every change with every useful test that people have accumulated for the software package, and when it seems ready for release, that release is done via Git tag. Doing local testing then becomes an option that you can use if you want a faster iteration cycle or better logs or local information than the CI can do, but routine patches can be tested only with CI without bothering to set up a full local development environment. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
