[pkg-go] Minutes for the DebConf17 BoF

[Michael Stapelberg]

On Sun, Aug 20, 2017 at 2:30 PM, Martín Ferrari <tincho at 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