Comment 41 for bug 1267393

@all

Given the timeline and the various other bits on our roadmap, I think main inclusion for juju core is *not* critical this cycle. We would rather get agreement, and get this done the right way than create last minute chaos for the release. But, it is critical that we sort this and the MRE out as cleanly and quickly as possible.

Juju is a key to our strategy of growing Ubuntu's presence in the server and cloud worlds, and we can't afford not to be united in our approach.

My understanding of the current state of the conversation is that we need to solve two major issues:

1) Package security update rules/processes for Go.
2) SimpleStreams/Tools not in the package issues

I think that we are making good progress on the first issue. It seems like there are both short and long term activities that need to happen, and which we can include in our various team plans for next cycle. We can get embedded libraries out, rebuild when needed, and simultaneously try to push forward the state of the art on either GCC go, or the state of dynamic linking on golang-go.

I am less sure about us being on a path towards consensus on the second item though... My belief is that the juju team is doing something completely sane given that they have a mandate to support multiple OS's, and a mandate to support cloud image distribution through simplestreams already. And I think that it is not at all fair to call juju a "installer package" since the external distribution of tools is mostly a "remote side" issue, where this juju client package is not installed at all.

Since we are dropping this MIR for this cycle, can we setup time to go through this issue across the teams, and get alignment after the release, but before the Juju cloud sprint at the end of April?

Also, if I'm missing any critical issues on which we have to have alignment, but don't, please raise them NOW rather than wait until the end of the next cycle -- so we can make sure we put aside time to deal with them properly this time.