On 12 August 2017 at 08:01, Martín Ferrari <tin...@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@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
_______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers