On Sun, May 18, 2014 at 9:55 PM, Menno Smits wrote:
> I'm working on a change to make "juju status" report the remote unit when
> a relation hook fails (https://bugs.launchpad.net/juju-core/+bug/1194481).
>
>
fwiw, i've updated to reflect that the underlying obscurity is much reduced
already via i
I wasn't suggesting that slices should be sorted in tests, but rather that
the real APIs define the ordering for elements stored and returned. This is
useful for humans too.
Either way, just a suggestion.
gustavo @ http://niemeyer.net
On May 22, 2014 5:49 PM, "Nate Finch" wrote:
> Although usin
I agree with Roger, I don't think a wrapper around Errgo is the right way
to go. If we don't like the way errgo behaves, we should change it. It's
our package, let's have it work the way we want it to work.
On Thu, May 22, 2014 at 10:47 AM, roger peppe wrote:
> On 14 May 2014 10:24, Tim Penhey
Although using DeepEquals on sorted lists does make for
easier-to-understand test failure messages, the burden on the developer to
sort the slices when they write the test doesn't seem worth it to me. We
write tests a lot more often than we need to debug failing tests. If it
was just slices of st
On 14 May 2014 10:24, Tim Penhey wrote:
> Hi all,
>
> I took it upon myself to get Rog's errgo library used inside juju-core.
Thanks for doing this.
> Dimiter recently did a hunk of work in the juju-core/errors package to
> have functions to add context to some core error types while keeping
> t
I apologize. After reading one of the review entries using
SameContents, I see I've misunderstood what the problem is about. The
v1 and v2 in your example is a slice, not a map, which means the test
is comparing slices of undefined order. This is certainly bogus and
needs addressing in the code its
On Wed, May 21, 2014 at 10:43 PM, Ian Booth wrote:
> We are working to make all juju-core unit tests pass using gccgo. In case you
> didn't already know, there's a common issue which has caused a lot of the
> failures to date. Here's a quick heads up on how to deal with it.
>
> golang-go and gcc-g
Sorry, I should have made it clearer - we are going to investigate how
best to do it without significantly slowing down landing time, and
running in parallel is an option. We'd really like to do it, but if we
can't then we can make it CI.
On Thu 22 May 2014 18:11:14 EST, John Meinel wrote:
> Pl
Please don't actually slow down the time it takes to land code to trunk by
actually running the tests 2x in a row (and IME gccgo test suite is
actually more than 1x the time for the golang test suite to run).
I suppose if you can put them in parallel, but I'd really like to see it
just be a CI test
