I know if we didn't retry constantly, the Juju tests'd never pass. But
by retrying, there is no impetus to fix them.
How about we stop retrying flaky tests? The blocked build get's the grease.
On Mon, Mar 28, 2016 at 5:23 PM, Martin Packman
wrote:
> On 27/03/2016, David Cheney wrote:
>> Hi Mart
On 27/03/2016, David Cheney wrote:
> Hi Martin,
>
> I was told that the Go 1.6 tests were voting, so these bugs should be
> blocking bugs. Is this not the case ?
The tests are voting, and giving blesses, so no blocking bugs, but a
lot of the remaining issues are low-occurrence failures. Basically
Hi Martin,
I was told that the Go 1.6 tests were voting, so these bugs should be
blocking bugs. Is this not the case ?
Thanks
Dave
On Fri, Mar 25, 2016 at 12:51 AM, Martin Packman
wrote:
> On 24/03/2016, Ian Booth wrote:
>>
>> Not yet. The builders and test infrastructure all need to be updat
The main issue I see is that Provider is all about interfacing upstream
(maas/ec2/etc) with the Juju abstraction. Which means that "
github.com/lxc/lxd" would end up importing "github.com/juju/juju". Which
from a layering perspective isn't right.
Gomaasapi is a bit unique as we're probably the onl
