[pkg-go] Minutes for the DebConf17 BoF

[Michael Hudson-Doyle]

On 12 August 2017 at 08:01, 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.
>

Makes sense tbh.


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

+1


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

Sounds good.


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

I think I /slightly/ prefer the upstream branch to be upstream's git
history not a series of imports of tarballs. But I'm not set on it, and gbp
doesn't really get on with this approach if you're just packaging a random
commit rather than a tag AFAICS.


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

Oh yes please.  Although the ideas that would let gbp import-orig --uscan
work without upstream tarballs would also be fine.


> Satta requested an option to disable SSL verification for badly
> configured redirection sites.
>
> 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.
>

It is also a random bag of stuff, it's not really the best bit of factoring
from upstream :)


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

Makes sense. Which gccgo arches are really being used today though? MIPS I
guess, but that really should get golang-go once we figure out how to do
that.


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

It would be good to have some automation and central resources around this
for sure.


> 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


Yeah, don't do this :)


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

https://nm.debian.org/process/198 :)

(Although the bottleneck is me answering my DAM currently...)


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

+100, _especially_ for -dev packages.

Cheers,
mwh

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.
>   * Standarisation & documentation of workflows: Tincho will send a
>     request to the ML.
>     - After discussion, will be merged into policy & dh-make-golang.
>   * 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20170816/b81f5ce4/attachment.html>