Otto Kekäläinen <o...@debian.org> writes: >> in addition to the above: gbp is great if it works, if it doesn't I can >> start to learn to debug a complex system, while on the contrary, if I use >> git and debuild/pbuilder/sbuild manually all the time, I know those tools, >> they are rather easy to debug etc. > > Personally I think gbp is very easy to debug. You just add --verbose > to any command and it will print out what it is doing. Example: > > ± gbp import-orig --uscan --verbose ...
I thought about the gbp aspect of the lets-move-things-to-salsa and I suggest to consider if they are better left orthogonal. Could you make one DEP for lets-move-to-salsa and one DEP for lets-document-a-build-workflow? The former would not talk a bout local builds at all. The latter would not talk about the Salsa workflow at all. They both intersect on git branch naming, and maybe some other minor aspects, but don't we have that already in DEP 14? Compare making packaging contributions to Debian to packaging contributions to Homebrew, Alpine, OpenWRT, ArchLinux, Guix, etc. There is a possibility to reach a completely git-based Salsa workflow for Debian packages that doesn't involve any local builds on people's laptops at all. This is comparable to Homebrew contributions, I find them a joy to work with in comparison and can contribute even without having any Homebrew development environment setup, or even without physical access to a Mac. There is no reason Debian packaging contributions couldn't work like that. Yes, old timers will continue build stuff on their laptop, and that has to be fine. We need to resolve how to authenticate archive uploads chaining back to a DD instead of PGP on tarball, but that is doable. /Simon
signature.asc
Description: PGP signature
