Re: juju/retry take 2 - looping

2016-10-25 Thread John Meinel
... > > I think this is a hint that this is the wrong approach. The edge-cases > begin showing the cracks in the abstraction and end up making the code more > complex. Consider your example instead of: > > var finalResult Foo > for loop := retry.Loop(spec); loop.Next(); { > result, err := Som

Re: juju/retry take 2 - looping

2016-10-25 Thread Katherine Cox-Buday
Tim Penhey writes: > Forcing continue/break does not make it like all boring imperative > loops. I would like to understand this better. Here's why I think they're boring: - They're Go keywords. - They're present in many other languages and are well understood. - I see breaks/continues all the

Re: juju/retry take 2 - looping

2016-10-25 Thread roger peppe
On 25 October 2016 at 22:40, Tim Penhey wrote: > On 26/10/16 10:30, Katherine Cox-Buday wrote: >> >> I think this is a hint that this is the wrong approach. The edge-cases >> begin showing the cracks in the abstraction and end up making the code more >> complex. Consider your example instead of: >

Re: juju/retry take 2 - looping

2016-10-25 Thread Tim Penhey
On 26/10/16 10:30, Katherine Cox-Buday wrote: I think this is a hint that this is the wrong approach. The edge-cases begin showing the cracks in the abstraction and end up making the code more complex. Consider your example instead of: var finalResult Foo for loop := retry.Loop(spec); loop.Nex

Re: juju/retry take 2 - looping

2016-10-25 Thread Katherine Cox-Buday
Tim Penhey writes: > The rationale behind that is to make the the library handle the 80% > case easily. The main reason of passing the error into Next is so you > don't have to do the check and explicit break within the loop. I will argue here that this goes against a core principle of Go which

Re: juju/retry take 2 - looping

2016-10-25 Thread Tim Penhey
Some comments first, then addressing issues: I thought it might help if I walked you through my thought process of making this change. * the purpose of the retry package is to provide a way to retry actions that may fail until they succeed, or some predetermined limit is hit * the way that f

Re: New functional-endpoint-bindings tests are non-voting

2016-10-25 Thread Dimiter Naydenov
On 10/25/2016 03:48 PM, Martin Packman wrote: > The new functional-endpoint-bindings tests on maas 2.0 and 2.1 are > non-voting while they gather a few runs and and the test environment > is tweaked. > > >

New functional-endpoint-bindings tests are non-voting

2016-10-25 Thread Martin Packman
The new functional-endpoint-bindings tests on maas 2.0 and 2.1 are non-voting while they gather a few runs and and the test environment is tweaked. Includes