On Tue, 04 Feb 2020 13:59:59 -0700, Sean Whitton wrote: > > Out of curiosity: Why? Which big advantages do you see with this > > workflow? > After tagging a new upstream release, and uploading to CPAN, I can stay > on the same git branch to do the Debian upload, i.e., > > % dzil release > % dch -v1.2.3-1 New upstream release. > % git commit debian/changelog -mchangelog > % git deborig > % dgit sbuild --run-autopkgtest --run-piuparts > % dgit push-source > % git push --follow-tags salsa master:master I see, thanks. I have to admit that this workflow has some elegance :) (And it needs some strictness to mentally separate upstream and debian work while still being in the same terminal/directory/branch. Luckily you're well prepared for that with your professional background :)) > > I don't see any real blockers, just some small disadvantages: Both > > our tools and the finger memories of many of us are focused on CPAN > > tarballs, so you might miss out on some minor features in tooling and > > cause minor confusion among potential other contributors amoung the > > team. > Okay -- if the confusion really did start to get in people's way, I > could switch over to CPAN tarballs. > Thanks -- will go ahead with using my workflow. Right, let's see how it goes for you [0] and others [1]. Cheers, gregor [0] E.g. when autopkgtests don't find a META.yml which is typically not in git but in the release tarball and you have to manually add a debian/tests/pkg-perl/use-name [1] There's no pristine-tar branch in your model, right? So if someone else wants to build the package, they have to download or re-create it somehow, I guess. -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Ben Weaver: Ocean ain't blue
Attachment:
signature.asc
Description: Digital Signature