<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 12 August 2017 at 08:01, Martín Ferrari <span dir="ltr"><<a href="mailto:tincho@tincho.org" target="_blank">tincho@tincho.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Pkg-go BoF meeting minutes<br>
==========================<br>
<br>
On Tuesday, we had the first in-person meeting of the team. We met for 2<br>
hours to discuss our current issues and to plan for the future.<br>
<br>
People present<br>
--------------<br>
<br>
Alexandre Viau (aviau)<br>
Martín Ferrari (Tincho)<br>
Paul Tagliamonte (paultag)<br>
Sascha Steinbiss (satta)<br>
<br>
Test files<br>
----------<br>
<br>
We discussed the issues raised about shipping test sources and fixtures<br>
in the -dev packages. It was pointed out that they are not really needed<br>
for autopkgtest or for reverse-dependencies, but that it will involve a<br>
lot of work to achieve, so we decided to keep them for now.<br></blockquote><div><br></div><div>Makes sense tbh.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Using -dev packages for development<br>
------------------------------<wbr>-----<br>
<br>
Due to the friction that can bring with upstreams, it was agreed to<br>
continue discouraging to use -dev packages for everyday golang development.<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Outdated packages and binNMUs<br>
-----------------------------<br>
<br>
Paultag proposed automating the detection of packages which have been<br>
compiled with old versions of libraries. He will implement a first<br>
version that just sends emails to remind of needed binNMUs, with the<br>
idea of some day automatically triggering wanna-build.<br>
<br>
He also indicated that he wants this automation to detect and warn about<br>
circular dependencies.<br></blockquote><div><br></div><div>Sounds good.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Git workflows<br>
-------------<br>
<br>
It was discussed about the problem of having so many different<br>
workflows, as it makes it difficult to work on packages prepared by<br>
other team members.<br>
<br>
The agreement was to find one standard and make it part of the team's<br>
policy and incorporate into dh-make-golang.<br>
<br>
To that end, it is requested that everyone sends an email to the mailing<br>
list describing their preferred workflow, and after a period of<br>
discussion we agree to a conclusion.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
dh-make-golang<br>
--------------<br>
<br>
A few times people expressed the desire for dh-make-golang to grow an<br>
`--update` option, as most packages are trivial to update, but tedious<br>
to do so.<br></blockquote><div><br></div><div>Oh yes please.  Although the ideas that would let gbp import-orig --uscan work without upstream tarballs would also be fine.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Satta requested an option to disable SSL verification for badly<br>
configured redirection sites.<br>
<br>
x/tools package<br>
---------------<br>
<br>
We discussed the current breakage in x/tools, and agreed that it is a<br>
core package and that we should make it a shared responsibility to keep<br>
it in a good shape.<br></blockquote><div><br></div><div>It is also a random bag of stuff, it's not really the best bit of factoring from upstream :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
gccgo support<br>
-------------<br>
<br>
We talked about the status of gccgo, paultag explained how mainline<br>
golang promises the compiler will always be buildable by gccgo, and how<br>
that makes bootstrapping and cross-building way simpler.<br>
<br>
We agreed on working towards making it a first-class citizen in the<br>
future, using golang-any by default, and only reverting to golang-go<br>
when needed.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
API changes in upstream<br>
-----------------------<br>
<br>
We ranted at length about upstreams, and noted that we need a system<br>
that provides early warning of API breakages. We discussed using ratt<br>
and autopkgtest for that purpose.<br></blockquote><div><br></div><div>It would be good to have some automation and central resources around this for sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Aviau pointed out that he usually requests upstreams to make releases<br>
and that he is usually successful. Tincho pointed out the problems with<br>
meaningless releases and with upstreams releasing once and then<br>
forgetting to do it when needed.<br>
<br>
We discussed the possibility of changing "soname"s by renaming packages<br>
when we detect API incompatibilities, but concluded that in general it<br>
is too much work</blockquote><div><br></div><div>Yeah, don't do this :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> and that it makes more sense to try and fix<br>
reverse-dependencies by bugging upstream or patching them ourselves.<br></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Team collaboration<br>
------------------<br>
<br>
On the topic of team collaboration, we agreed to avoid using the DM ACL<br>
mechanism too much, and instead help active contributors to become DDs.<br></blockquote><div><br></div><div><a href="https://nm.debian.org/process/198">https://nm.debian.org/process/198</a> :)<br></div><div><br></div><div>(Although the bottleneck is me answering my DAM currently...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We also revisited the policy on team uploads, and concluded that we want<br>
to continue with avoiding hard ownership of packages and that by default<br>
everything is team-maintained.<br></blockquote><div><br></div><div>+100, _especially_ for -dev packages.</div><div> </div><div>Cheers,</div><div>mwh</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Plan of action<br>
--------------<br>
<br>
There was some talk about things to do in the immediate future to<br>
improve the team work:<br>
<br>
  * paultag will work on automated binNMU need detection<br>
  * Automated updating and testing of packages.<br>
  * Standarisation & documentation of workflows: Tincho will send a<br>
    request to the ML.<br>
    - After discussion, will be merged into policy & dh-make-golang.<br>
  * aviau volunteers to document dh_golang options.<br>
  * satta is going to take a look at policy cleanup.<br>
<br>
Thanks to all for participating!<br>
<br>
Tincho.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
Martín Ferrari (Tincho)<br>
<br>
______________________________<wbr>_________________<br>
Pkg-go-maintainers mailing list<br>
<a href="mailto:Pkg-go-maintainers@lists.alioth.debian.org">Pkg-go-maintainers@lists.<wbr>alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers" rel="noreferrer" target="_blank">http://lists.alioth.debian.<wbr>org/cgi-bin/mailman/listinfo/<wbr>pkg-go-maintainers</a></font></span></blockquote></div><br></div></div>