"Does the MIR/security teams seriously consider pulling all of
golang/those static builds into main?"

This issue is quite complicated and slippery. Basically, the decision
had been taken in Oakland last November that gccgo is the toolchain
Ubuntu Engineering would support on the client and the foundations and
security teams don't consider gc supportable from a distro standpoint
due to the static linking issue. For the client, promoting golang would
mean Ubuntu is not being responsible because we are making all these
developers responsible for tracking *our* security and high impact bug
fixes. On the client, I don't care if app developers embed some library
that we don't provide-- that's on them to keep up to date, but I very
much care if we ship a runtime as a standard part of Ubuntu/the SDK that
developers are expected to use and we can't provide the fixes for them
automatically.

That said, this MIR is about golang in support of juju for server/cloud,
but the issue still remains-- we need to make sure we have something
supportable. If golang is promoted to main, it is clear to me the Go
community would rejoice and use it immediately, but then 3rd party
developers will have to track Ubuntu's security fixes and recompile
their applications on their own. Sure, we could add a note to the USN
that people need to recompile their applications if they use golang, but
USNs are not widely read and this practice is far outside the norm for
updating stable releases and people will miss the fixes.

To paraphrase Steve Langasek from foundations, if there are blockers for
the use of gccgo as the compiler, we should know what those are and we
should be fixing those. Personally, my thinking is that if golang is
truly the future and what the Go community and Canonical devs want,
perhaps we should put resources behind fixing the upstream bug:
http://code.google.com/p/go/issues/detail?id=256 (which incidentally,
doesn't seem to have progressed in a long time).

The foundations and security team's stance is clear: if we ship something in 
Ubuntu in main, we need to be responsible for it and make sure people can get 
their updates. Moving forward, I see several options in my personal order of 
preference:
 1. put resources behind the golang dynamic linking upstream bug and fix it
 2. fix gccgo for the juju use case and/or update gccgo to a new version if one 
exists
 3. allow golang into main with very strong wording that it is only for juju 
and that 3rd party developers are on their own

'1' is by far my preferred solution because it would end this once and
for all. I don't like '3' and I think it will tarnish Ubuntu's
reputation. If we go for '3', a condition of the MIR would be reviewing
where we declare the lack of support (an idea I had would be outputting
a string at the beginning or end of the compile). Other options may
exist, but I know the foundations team looked into them and my
understanding is that '1' and '2' are really the only choices.

** Bug watch added: Go Issue Tracker #256
   http://code.google.com/p/go/issues/detail?id=256

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
https://bugs.launchpad.net/bugs/1267393

Title:
  [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Reply via email to