[pkg-go] Minutes for the DebConf17 BoF

[Michael Stapelberg]

On Sun, Aug 20, 2017 at 5:35 PM, Martín Ferrari <tincho at tincho.org> wrote:
> So, my turn to describe workflows.
>
> I use gbp, pristine-tar, cowbuilder (but planning to move to sbuild),
> dch, debcommit as my main tools. I have not really used dh-make-golang much.
>
> My global gbp configuration is as follows:
>
> [DEFAULT]
> pristine-tar = True
> sign-tags = True
>
> [buildpackage]
> export = WC
> postbuild = lintian $GBP_CHANGES_FILE && debsign $GBP_CHANGES_FILE
> export-dir = ../build-area/
> tarball-dir = ../tarballs/
> ignore-new = True
> pbuilder = True
>
> [import-orig]
> postimport = dch -v%(version)s New upstream release.
>
>
> In general, I try to keep existing structures in git, but for packages I
> prepare, I use DEP14 branches and tags:
>
>  * HEAD is debian/sid, other dists are debian/<dist>.
>  * upstream/<version> tag for unpacked upstream source.
>  * debian/<version> tag for uploaded packages.
>  * I keep an "upstream" branch for unpackaged upstream sources, which is
> tagged and then merged into the main packaging branch.
>
> Depending on upstream having releases or not, I either use gbp
> import-orig --uscan, or follow git history with an "upstream" remote. In
> both cases, the sources end in a git branch.
>
> For repackaging, I either use "excluded-files" in debian/changelog for
> released projects, or create a second upstream branch "repackaged",
> "unvendored", or somesuch, where I make changes and merge from
> "upstream" after every import.
>
> For the go ecosystem, I am feeling it is much more useful and productive
> to keep complete upstream history than using the releases, and for some
> packages with releases I started using this. It pays off every time I
> need to troubleshoot api changes, backport fixes, and the such..

Side note, not meant to persuade anyone one way or the other: I just
realized why I never saw any appeal in that argument: I find git
packaging (or git in general?) too brittle and confusing to keep what
I consider are multiple projects in the same repository.

When I need to find out something about upstream repositories, I
usually use the GitHub web interface, or my local gopath. I never use
the git packaging repos, regardless of whether they have history or
not.

>
> When I am doing this, I add this gbp.conf snippet in the debian/ directory:
>
> [buildpackage]
> dist = DEP14
> upstream-tag = upstream/%(version)s
> pristine-tar = True
> pristine-tar-commit = True
>
> For simplifying pushes, I also add this config:
>
> $ git config --add remote.debian.push 'refs/heads/debian/*'
> $ git config --add remote.debian.push 'refs/heads/upstream'
> $ git config --add remote.debian.push 'refs/heads/pristine-tar'
> $ git config --add remote.debian.push 'refs/tags/debian/*'
> $ git config --add remote.debian.push 'refs/tags/upstream/*'
> $ git config --add remote.debian.fetch 'refs/tags/*:refs/tags/*'

Good point, I use:

        git config --add remote.origin.push "+refs/heads/*:refs/heads/*"
        git config --add remote.origin.push "+refs/tags/*:refs/tags/*"

But note that gbp recently gained “gbp push”:
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=cbacdfb40ca35633da06e9e05497ac0fb56cc4f9

It’s included in 0.9.0~exp2, but I haven’t tried it out yet.
Hopefully, it makes both our extra setup steps unnecessary :).

>
>
> My preference for debian/changelog is:
>  * distribution=UNRELEASED until the package is ready to upload.
>  * I use dch for every change, and debcommit to commit with that same
> message.
>  * dch -r when package is ready for upload (changes dist).
>  * debcommit -r after uploading (creates signed tag).

Given that you _also_ maintain history in git, using gbp dch seems
like significantly cutting down the number of commands. Is there any
rationale behind your decision to not use gbp dch, or are you just
used to this way? :)

>
>
> My workflow with upstream history is as this:
>
> 1. Init
>
> (on alioth)
>
> $ /git/pkg-go/setup-repository foo
> $ git --git-dir=/git/pkg-go/packages/... symbolic-ref HEAD
> refs/heads/debian/sid
>
> (locally)
> $ git remote add upstream https://...
> $ git remote add debian ssh://git.debian.org/git/pkg-go/packages/...
> $ git fetch --all
> $ git checkout -b upstream upstream/master # or upstream tag
> $ git tag upstream/0.0+gitYYYYMMDD.NNNNNNN
> # optional, if repackaging is needed.
> $ git ckeckout -b repackaged
> $ git rm -rf vendor/; git commit -m repackage
> $ git tag upstream/0.0+gitYYYYMMDD.NNNNNNN-ds
> $ git checkout -b debian/sid
> # create debian/* stuff, with dh-make-golang, or (usually) copy from
> another package :-). Add gbp.conf snippet, git config, etc
>
> 2. Update
>
> $ git fetch --all
> $ git checkout debian/sid
> $ git tag upstream/0.0+gitYYYYMMDD.NNNNNNN NNNNNNN
> $ git merge upstream/0.0+gitYYYYMMDD.NNNNNNN
> $ dch -v 0.0+gitYYYYMMDD.NNNNNNN-1 'New upstream snapshot.'
> $ git add debian/changelog; debcommit
> $ gbp buildpackage  # This also creates the pristine tar from the tag.
>
> 3. Work on the package
>
> # Fix stuff
> $ dch 'debian/foo: fix bar'; debcommit -a
>
> # When finished
> $ dch -r
> $ git add debian/changelog; debcommit
> $ gbp buildpackage
>
> $ dput <changes file>
> $ debcommit -r
> $ git push debian
>
>
> For backports is all the same, except that instead of using debian/sid,
> I fork a debian/stretch-backports and work from there.
>
> _______________________________________________
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
Best regards,
Michael