[pkg-go] Minutes for the DebConf17 BoF

[Martín Ferrari]

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.

> 2. My ~/.gbp.conf reads https://paste.debian.net/hidden/a48afca2/
> <https://paste.debian.net/hidden/a48afca2/> (informational)

Sadly, this has expired

> 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).

> 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)