James, Thanks for the detailed write up straight from the trenches :)
-- Dims On Thu, May 12, 2016 at 5:58 AM, James Page <james.p...@ubuntu.com> wrote: > On Mon, 9 May 2016 at 19:32 Monty Taylor <mord...@inaugust.com> wrote: > [...] >> >> [> The point here though, is that the versions of Python that OpenStack >> > has traditionally supported have been directly tied to what the Linux >> > distributions carry in their repositories (case in point, Python 2.6 >> > was dropped from most things as soon as RHEL7 was available with Python >> > 2.7). With Go, there might need to be similar restrictions. >> >> Since this is a forward-facing thing, I think starting with the version >> that's in xenial is probably fine for today, yeah? That will be the >> version of go that will get installed in the gate starting with this >> cycle. > > > Apologies for commenting late on this thread - I needed to catchup with the > Go maintainer in Ubuntu (CC'ed) to get things straight from an Ubuntu > perspective. > > a) Distribution of Go based projects in Ubuntu > > tl;dr - we've been dealing with distribution of large Go projects in Ubuntu > for a number of years - so no problem if OpenStack wants to support Go as an > official language > > Ubuntu supports at least three large Go codebases in archive as of Xenial - > Juju, LXD and Snappy are all written in Go, and as a result we've had a > focus on how to support them for end-users over the last few years. > > As Monty points out, Golang 1.6 is the released version of Go in Xenial (and > its also installable for Trusty - "apt-get install golang-1.6-go"); that > said the way the packaging has been done, its possible to introduce newer > golang versions without breaking the existing Go based packages in the > Ubuntu archive at any point in time; The three Canonical projects in > archive are using 1.6 as a baseline for compatibility to make things a > little easier to manage; 1.6 will remain as the default Go version, but > newer versions may be introduced in parallel. > > In terms of where code for dependencies of projects sits, Ubuntu has taken a > flexible stance on this - for components where version alignment is good and > there is good reason to want to identify the versions being used across a > number of packages, a separate golang-XXX package is produced - this allows > the Ubuntu Security team to monitor for CVE's, allowing for more effective > security support. A good example of this is the go.crypto package. For > dependencies used by a single project, or where there is not alignment with > the packaged golang-XXX version, we're continuing to use the version > embedded by the consuming project. > > The Debian toolchain around Go packages helps with managing this by adding > 'Built-Using' fields to all Go binary packages that depend on separate > golang-XXX packages - which means that the archive keeps track of what was > used to produce a particular binary package. This allows the distro to > easily analyse what needs rebuilding when a shared golang-XXX package is > fixed/updated in some way, as well as letting us deal with things like > transitions between Go versions (the golang package version is also embedded > in this data). > > Shared library support is coming in Ubuntu (and Debian) for Go; however we > think its something that adds value to the distributor (avoiding rebuilds > for fully statically linked binaries) rather than the developer (esp in the > context of security management). Oh and its still really new... > > b) General technical feedback on Go development in the context of OpenStack > > Note that I'm not a Go developer, but have been observing Go development > across a number of large Go codebases - these are things I've seen that help > both the development team and the distributors of their work. > > i) Use godeps for dependency management > > This is used across Juju, LXD and Snappy to manage dependencies at specific > commits/revisions and has proved invaluable. > > ii) Don't embedded your dependencies in your VCS repository > > Ideally when you cut a release artefact, bundle up the dependencies at this > point in time using godeps. > > iii) Agree baseline versions > > For each OpenStack release agree a baseline golang version, and common > version alignment on dependencies where appropriate. > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
