Re: [Proposal] Requiring Go 1.2 across the board
On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.comwrote: Hello, This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Motivation: * Now that T is out, we have to support Juju on two series (Precise and Trusty[1]) with two compilers, gc and gccgo. * gccgo-4.9, which is version we using in trusty, supports the Go 1.2 spec * gc-1.1.2 which is available in a ppa for precise, obviously supports Go 1.1 * gc-1.2.1 is the shipping compiler on Trusty, it supports Go 1.2 So now we have three compilers, two versions of gc, and one of gccgo. We are in the situation where code written for gccgo under T on ppc64 or armv8 will not pass the bot running Go 1.1.1. For this reason I would like to reduce this matrix. Recommendation: * Get the trusty compiler into a backport ppa for precise[1] * Upgrade the bot to use that compiler, raising the minimum compiler spec to 1.2 across the board SGTM. The bot will be changing soon to a Jenkins lander; seems like an opportune time for making the change. Thoughts / Discussion / Spoiled fruit ? Dave [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: [Proposal] Requiring Go 1.2 across the board
William, could you please raise this at the team leads meeting tonight on my behalf. The steps look quite straight forward, they just need to go on a card and get done. On Fri, May 16, 2014 at 5:53 PM, William Reade william.re...@canonical.com wrote: +1 On Fri, May 16, 2014 at 9:18 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.com wrote: Hello, This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Motivation: * Now that T is out, we have to support Juju on two series (Precise and Trusty[1]) with two compilers, gc and gccgo. * gccgo-4.9, which is version we using in trusty, supports the Go 1.2 spec * gc-1.1.2 which is available in a ppa for precise, obviously supports Go 1.1 * gc-1.2.1 is the shipping compiler on Trusty, it supports Go 1.2 So now we have three compilers, two versions of gc, and one of gccgo. We are in the situation where code written for gccgo under T on ppc64 or armv8 will not pass the bot running Go 1.1.1. For this reason I would like to reduce this matrix. Recommendation: * Get the trusty compiler into a backport ppa for precise[1] * Upgrade the bot to use that compiler, raising the minimum compiler spec to 1.2 across the board SGTM. The bot will be changing soon to a Jenkins lander; seems like an opportune time for making the change. Thoughts / Discussion / Spoiled fruit ? Dave [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
What is required to switch back to using the tip of goose ?
Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: [Proposal] Requiring Go 1.2 across the board
I believe the team lead meeting is last night, not tonight. I'm fine with this, AFAIK the only specific change that needs to be made is to get golang-go 1.2.* into ppa:juju/golang. I hope the people (Curtis and Ian) are still planning on configuring the new Jenkins lander as a Precise machine, since I still expect that to be the place where we are the most likely to accidentally break things. (Most developers will be running Trusty, so are likely to catch issues there.) John =:- On Fri, May 16, 2014 at 11:56 AM, David Cheney david.che...@canonical.comwrote: William, could you please raise this at the team leads meeting tonight on my behalf. The steps look quite straight forward, they just need to go on a card and get done. On Fri, May 16, 2014 at 5:53 PM, William Reade william.re...@canonical.com wrote: +1 On Fri, May 16, 2014 at 9:18 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.com wrote: Hello, This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Motivation: * Now that T is out, we have to support Juju on two series (Precise and Trusty[1]) with two compilers, gc and gccgo. * gccgo-4.9, which is version we using in trusty, supports the Go 1.2 spec * gc-1.1.2 which is available in a ppa for precise, obviously supports Go 1.1 * gc-1.2.1 is the shipping compiler on Trusty, it supports Go 1.2 So now we have three compilers, two versions of gc, and one of gccgo. We are in the situation where code written for gccgo under T on ppc64 or armv8 will not pass the bot running Go 1.1.1. For this reason I would like to reduce this matrix. Recommendation: * Get the trusty compiler into a backport ppa for precise[1] * Upgrade the bot to use that compiler, raising the minimum compiler spec to 1.2 across the board SGTM. The bot will be changing soon to a Jenkins lander; seems like an opportune time for making the change. Thoughts / Discussion / Spoiled fruit ? Dave [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: What is required to switch back to using the tip of goose ?
AFAIK there is one patch which landed a couple of days ago that changes an API that used to only return an io.ReadCloser, error that now returns io.ReadCloser, Headers, error, and we can safely ignore the Headers (someone else needed it who wanted to use goose). I think the only reason we aren't running an updated version is because nobody has cared to do so. I believe it is a 3 character fix for Get() but I haven't really tested the rest. John =:- On Fri, May 16, 2014 at 12:47 PM, David Cheney david.che...@canonical.comwrote: Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: What is required to switch back to using the tip of goose ?
There also appears to be a small API breakage # launchpad.net/juju-core/provider/openstack provider/openstack/storage.go:59: assignment count mismatch: 2 = 3 On Fri, May 16, 2014 at 7:48 PM, John Meinel j...@arbash-meinel.com wrote: AFAIK there is one patch which landed a couple of days ago that changes an API that used to only return an io.ReadCloser, error that now returns io.ReadCloser, Headers, error, and we can safely ignore the Headers (someone else needed it who wanted to use goose). I think the only reason we aren't running an updated version is because nobody has cared to do so. I believe it is a 3 character fix for Get() but I haven't really tested the rest. John =:- On Fri, May 16, 2014 at 12:47 PM, David Cheney david.che...@canonical.com wrote: Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: What is required to switch back to using the tip of goose ?
Oh yes, we are talking about the same thing. I'll propose a branch On Fri, May 16, 2014 at 7:50 PM, David Cheney david.che...@canonical.com wrote: There also appears to be a small API breakage # launchpad.net/juju-core/provider/openstack provider/openstack/storage.go:59: assignment count mismatch: 2 = 3 On Fri, May 16, 2014 at 7:48 PM, John Meinel j...@arbash-meinel.com wrote: AFAIK there is one patch which landed a couple of days ago that changes an API that used to only return an io.ReadCloser, error that now returns io.ReadCloser, Headers, error, and we can safely ignore the Headers (someone else needed it who wanted to use goose). I think the only reason we aren't running an updated version is because nobody has cared to do so. I believe it is a 3 character fix for Get() but I haven't really tested the rest. John =:- On Fri, May 16, 2014 at 12:47 PM, David Cheney david.che...@canonical.com wrote: Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Making juju work better with gccgo
FWIW, I wrote this little bash function and put it in my ~/.bashrc
function gotest {
p=-gocheck.v
f=
if [ -n $1 ]; then
if [ $1 = -r ]; then
p=./...
else
f=-gocheck.f=$f
fi
fi
go test $p $f go test -compiler=gccgo $p $f
}
That lets my write:
gotest
gotest -r
and
gotest justOneSuite
I'm sure something better could be done, but that makes things immediately
useful.
The compile time is noticeably slower at getting the tests running (so this
slows down iteration 2x), but until gccgo is ironed out it is probably
still worthwhile.
John
=:-
On Fri, May 16, 2014 at 6:53 AM, David Cheney david.che...@canonical.comwrote:
Thanks Tim,
I think we're in the position that even if you don't use gccgo for
your own development (understandable, it is slower), now that we have
platforms we support in Trusty that must use gccgo, armv8 and ppc64el,
for any new development, the code has to pass under both compilers.
This is a bit of a bummer, but at least if you are running trusty on
your development environment, you have all the bits you need[1][2].
Running tests, for a single package then becomes
go test go test -compiler=gccgo
With respect to the whole Juju test suite, even after months of work
there still remain a few tests which do not pass under trusty, these
are tracked with bugs in lp, just look for the gccgo label if you find
yourself at a loose end.
Cheers
Dave
[1] Prior to trusty, you'd probably be using gccgo-4.8, which is not
of acceptable quality for use with Juju.
[2] If for some reason you don't want to upgrade to trusty, we may be
able to ask Doko for a backport of gccgo-4.9, but really, just upgrade
to trusty.
On Fri, May 16, 2014 at 12:44 PM, Tim Penhey tim.pen...@canonical.com
wrote:
I realise I left this bit hanging:
On 16/05/14 14:41, Tim Penhey wrote:
A key issue that Dave and I have been poking with a stick is the test
suite for juju/errgo, as it had some failures with gccgo (all passed
with gc).
In the end it had to do with the runtime.Caller method for stack
analysis, and the synthetic methods that gccgo was creating. The
solution was simply enough to convert the tests to use gocheck, that way
the synthetic methods that were being created are higher in the stack
that we ever look in the tests, and it is all good.
Tim
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: What is required to switch back to using the tip of goose ?
FYI. This change has landed, please do the godeps dance. On Fri, May 16, 2014 at 7:54 PM, David Cheney david.che...@canonical.com wrote: Oh yes, we are talking about the same thing. I'll propose a branch On Fri, May 16, 2014 at 7:50 PM, David Cheney david.che...@canonical.com wrote: There also appears to be a small API breakage # launchpad.net/juju-core/provider/openstack provider/openstack/storage.go:59: assignment count mismatch: 2 = 3 On Fri, May 16, 2014 at 7:48 PM, John Meinel j...@arbash-meinel.com wrote: AFAIK there is one patch which landed a couple of days ago that changes an API that used to only return an io.ReadCloser, error that now returns io.ReadCloser, Headers, error, and we can safely ignore the Headers (someone else needed it who wanted to use goose). I think the only reason we aren't running an updated version is because nobody has cared to do so. I believe it is a 3 character fix for Get() but I haven't really tested the rest. John =:- On Fri, May 16, 2014 at 12:47 PM, David Cheney david.che...@canonical.com wrote: Why is the Openstack provider pinned to an old version of lauchpad.net/goose ? What is required to use the latest version ? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: [Proposal] Requiring Go 1.2 across the board
On Fri, May 16, 2014 at 5:44 AM, John Meinel j...@arbash-meinel.com wrote: to get golang-go 1.2.* into ppa:juju/golang. I hope the people (Curtis and Ian) are still planning on configuring the new Jenkins lander as a Precise machine, since I still expect that to be the place where we are the most likely to accidentally break things. (Most developers will be running Trusty, so are likely to catch issues there.) We are reaching the limits of my backporting skill. Next week I will attempt a backport to verify Lp will let me build for precise and saucy. If I get binaries, I can setup unit test runs for both series on machines with the new package. If everything passes, I will then copy the package to golang. We will also need to put golang into ctools: http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/g/golang/ -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: [Proposal] Requiring Go 1.2 across the board
+1 On May 16, 2014 3:53 AM, William Reade william.re...@canonical.com wrote: +1 On Fri, May 16, 2014 at 9:18 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.com wrote: Hello, This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Motivation: * Now that T is out, we have to support Juju on two series (Precise and Trusty[1]) with two compilers, gc and gccgo. * gccgo-4.9, which is version we using in trusty, supports the Go 1.2 spec * gc-1.1.2 which is available in a ppa for precise, obviously supports Go 1.1 * gc-1.2.1 is the shipping compiler on Trusty, it supports Go 1.2 So now we have three compilers, two versions of gc, and one of gccgo. We are in the situation where code written for gccgo under T on ppc64 or armv8 will not pass the bot running Go 1.1.1. For this reason I would like to reduce this matrix. Recommendation: * Get the trusty compiler into a backport ppa for precise[1] * Upgrade the bot to use that compiler, raising the minimum compiler spec to 1.2 across the board SGTM. The bot will be changing soon to a Jenkins lander; seems like an opportune time for making the change. Thoughts / Discussion / Spoiled fruit ? Dave [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: [Proposal] Requiring Go 1.2 across the board
fwiw the only interim release still under support is S (along with lts releases of L, P, T). interim releases get 9 months of support, and S expires in July. https://wiki.ubuntu.com/Releases On Fri, May 16, 2014 at 9:15 AM, Gustavo Niemeyer gust...@niemeyer.netwrote: On Fri, May 16, 2014 at 4:08 AM, David Cheney david.che...@canonical.com wrote: This is a proposal that we raise the minimum Go spec from Go 1.1 to Go 1.2. Sounds sensible. [1] I am ignoring the intermediate, non LTS series', as there are no charms for them, nor do CTS offer support for them. If this is unacceptable, anything which applies to Precise wrt. backports, also applies to Q, R and S. I suppose we do want people using these releases on their own machines to be able to use juju, at least as a client. What's the proposed mechanism for getting it to them? gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
