[pkg-go] Minutes for the DebConf17 BoF

Tue Aug 15 21:02:39 UTC 2017

Thanks for sending these out. Comments inline:

On Fri, Aug 11, 2017 at 10:01 PM, Martín Ferrari <tincho at tincho.org> wrote:

> Pkg-go BoF meeting minutes
> ==========================
>
> On Tuesday, we had the first in-person meeting of the team. We met for 2
> hours to discuss our current issues and to plan for the future.
>
> People present
> --------------
>
> Alexandre Viau (aviau)
> Martín Ferrari (Tincho)
> Paul Tagliamonte (paultag)
> Sascha Steinbiss (satta)
>
> Test files
> ----------
>
> We discussed the issues raised about shipping test sources and fixtures
> in the -dev packages. It was pointed out that they are not really needed
> for autopkgtest or for reverse-dependencies, but that it will involve a
> lot of work to achieve, so we decided to keep them for now.
>
> Using -dev packages for development
> -----------------------------------
>
> Due to the friction that can bring with upstreams, it was agreed to
> continue discouraging to use -dev packages for everyday golang development.
>
> Outdated packages and binNMUs
> -----------------------------
>
> Paultag proposed automating the detection of packages which have been
> compiled with old versions of libraries. He will implement a first
> version that just sends emails to remind of needed binNMUs, with the
> idea of some day automatically triggering wanna-build.
>
> He also indicated that he wants this automation to detect and warn about
> circular dependencies.
>
> Git workflows
> -------------
>
> It was discussed about the problem of having so many different
> workflows, as it makes it difficult to work on packages prepared by
> other team members.
>
> The agreement was to find one standard and make it part of the team's
> policy and incorporate into dh-make-golang.
>
> To that end, it is requested that everyone sends an email to the mailing
> list describing their preferred workflow, and after a period of
> discussion we agree to a conclusion.
>

This sounds very good.

I have come to appreciate the following properties of working with
git-buildpackage:

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.

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

3. To import a new upstream version, I run `gbp import-orig --uscan`. This
of course only works with tagged releases until #811565 is fixed (hopefully
soon).

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.

5. I use quilt for managing patches, and am reasonably happy with that,
i.e. I personally don’t see the need for anything more fancy than that,
especially given that we usually only carry very few patches per package.
Some of our packages use branches which only contain debian/, 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/.

Here are some more thoughts, not directly related to how I maintain my own
packages:

6. I have come to appreciate pristine-tar, as it is the only reliable way
(that I know of) to prepare uploads for packages which already have their
orig tarball in Debian. Whenever I come across a package which isn’t using
pristine-tar, the generated orig tarball will have a different checksum,
and my upload will be rejected. I’d suggest we codify that pristine-tar is
a requirement.

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.

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.

Thoughts? :)

>
> dh-make-golang
> --------------
>
> A few times people expressed the desire for dh-make-golang to grow an
> `--update` option, as most packages are trivial to update, but tedious
> to do so.
>

See point ③ above — I’m optimistic that we can use uscan for that soon.

>
> Satta requested an option to disable SSL verification for badly
> configured redirection sites.
>

Which sites are affected? Did we try contacting the maintainers and fix
their config? In the days of LetsEncrypt, it seems easier to just fix the
site.

>
> x/tools package
> ---------------
>
> We discussed the current breakage in x/tools, and agreed that it is a
> core package and that we should make it a shared responsibility to keep
> it in a good shape.
>
> gccgo support
> -------------
>
> We talked about the status of gccgo, paultag explained how mainline
> golang promises the compiler will always be buildable by gccgo, and how
> that makes bootstrapping and cross-building way simpler.
>
> We agreed on working towards making it a first-class citizen in the
> future, using golang-any by default, and only reverting to golang-go
> when needed.
>
> API changes in upstream
> -----------------------
>
> We ranted at length about upstreams, and noted that we need a system
> that provides early warning of API breakages. We discussed using ratt
> and autopkgtest for that purpose.
>
> Aviau pointed out that he usually requests upstreams to make releases
> and that he is usually successful. Tincho pointed out the problems with
> meaningless releases and with upstreams releasing once and then
> forgetting to do it when needed.
>
> We discussed the possibility of changing "soname"s by renaming packages
> when we detect API incompatibilities, but concluded that in general it
> is too much work and that it makes more sense to try and fix
> reverse-dependencies by bugging upstream or patching them ourselves.
>
> Team collaboration
> ------------------
>
> On the topic of team collaboration, we agreed to avoid using the DM ACL
> mechanism too much, and instead help active contributors to become DDs.
>
> We also revisited the policy on team uploads, and concluded that we want
> to continue with avoiding hard ownership of packages and that by default
> everything is team-maintained.
>
> Plan of action
> --------------
>
> There was some talk about things to do in the immediate future to
> improve the team work:
>
>   * paultag will work on automated binNMU need detection
>   * Automated updating and testing of packages.
>

I wanted to propose some tooling for this, but I think it makes sense to
wait with that until after the Alioth sprint: ideally, we’d get an alioth
replacement with support for continuous integration, at which point we
could just create a pull request with a new version, wait for the CI result
(using ratt) and merge if all looks good.

>   * Standarisation & documentation of workflows: Tincho will send a
>     request to the ML.
>     - After discussion, will be merged into policy & dh-make-golang.
>

I hope you don’t mind that I replied directly to this thread :)

>   * aviau volunteers to document dh_golang options.
>   * satta is going to take a look at policy cleanup.
>
> Thanks to all for participating!
>
> Tincho.
>
> --
> Martín Ferrari (Tincho)
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20170815/76743d8d/attachment-0001.html>