On Sun, Aug 20, 2017 at 2:30 PM, Martín Ferrari <tin...@tincho.org> wrote: > Hi Mickael, > > I haven't yet got the time to write down properly my workflow, but I > will still reply to some points. :) > > On 15/08/17 23:02, Michael Stapelberg wrote: > >> 1. I store packaging in e.g. ~/d/pkg/gocryptfs and build using `gbp >> buildpackage --git-export-dir=~/d/out/gocryptfs`. By using >> --git-export-dir, my working copy always stays clean. By collecting the >> output files per package, I can easily debdiff between versions. This >> point is informational and shouldn’t have any bearing on a canonical >> workflow. > > Why do you need this? I use gbp with cowbuilder, and so the working copy > is never touched. Looking at my gbp.conf, I see my default is to export > to '../build-area', but probably that does not change much.
I use gbp with sbuild, and I do see different behavior with/without exporting. Take for example the freeradius repository, where the build fails without git-export-dir: https://paste.debian.net/982241/ > >> 2. My ~/.gbp.conf reads https://paste.debian.net/hidden/a48afca2/ >> <https://paste.debian.net/hidden/a48afca2/> (informational) > > Sadly, this has expired Sorry about that. Here’s one that shouldn’t expire: https://paste.debian.net/982242/ > >> 4. To update debian/changelog, I run `gbp dch -R --commit`. Note that >> this goes against our current policy of editing debian/changelog with an >> UNRELEASED entry — when using gbp-dch, the changelog is entirely >> auto-generated from git (but you do have the option to amend it before >> committing). Hence, I’d suggest we update that policy and start using >> gbp-dch. > > This is one of these things were we should decide on one way to do > things, as it is incompatible with the other usual way, which is to > change debian/changelog on every commit. > >> not the upstream source. This breaks quilt and confuses me. I’d suggest >> we codify that the branch must contain the upstream sources plus debian/. > > +1 > >> different checksum, and my upload will be rejected. I’d suggest we >> codify that pristine-tar is a requirement. > > +1 > >> 7. We don’t currently have a guideline with regards to branch naming, >> especially when maintaining branches for multiple debian versions (e.g. >> stretch, buster, stretch-backports, …). I’d suggest we adopt the >> debian/<suite> branch naming scheme, e.g. debian/buster is the default >> branch, backports can be found in debian/stretch-backports, etc. > > I have adopted DEP-14, which is basically this, and makes it very > pleasant to work with different distributions, specially since I have > been doing a lot of backporting. > > One caveat: the default branch should (according to DEP-14) not be > debian/buster, but debian/sid (or just master). Thanks for the pointer, I wasn’t aware of DEP-14 yet. We should definitely adopt it. > >> 8. (Optional/best effort) I recently came to understand that dgit is >> thought of as a universal approach for new users/maintainers to easily >> contribute to packaging (you get the same style of git checkout of any >> package in the archive). We should verify the above constraints still >> leave us in a place where dgit works well — it will work for any >> package, but it will work better for packages which are `dgit push`ed. I >> don’t yet know what the requirements for that are. > > Same here, I haven't checked it out yet > > -- > Martín Ferrari (Tincho) -- Best regards, Michael _______________________________________________ Pkg-go-maintainers mailing list Pkgemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers