+1 to reserving the juju* space just as we do with relations and such.
On Mon, Mar 28, 2016 at 10:12 PM Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:
> On Tue, Mar 29, 2016 at 10:03 AM Marco Ceppi
> wrote:
>
>> On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins <
On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins
wrote:
> Hi,
>
> There's a code review in progress (http://reviews.vapour.ws/r/4286/) that
> will introduce a predefined action, "juju-run", which is part of the
> replacement for the current SSH-based juju-run.
>
This
Hi,
There's a code review in progress (http://reviews.vapour.ws/r/4286/) that
will introduce a predefined action, "juju-run", which is part of the
replacement for the current SSH-based juju-run.
This means that "juju-run" will no longer be a valid action name for use in
a charm. This may come up
On Monday, March 28, 2016, Ian Booth wrote:
> Hey Antonio
>
> I must apologise - the changes didn't make beta3 due to all the work
> needed to
> migrate the CI scripts to test the new hosted model functionality; we ran
> out of
> time to be able to QA the local bundle
Hey Antonio
I must apologise - the changes didn't make beta3 due to all the work needed to
migrate the CI scripts to test the new hosted model functionality; we ran out of
time to be able to QA the local bundle changes.
I expect this work will be done for beta4.
On 29/03/16 11:04, Antonio
+ Juju list for others awareness
On Thu, Mar 10, 2016 at 1:53 PM, Ian Booth wrote:
> Thanks Rick. Trivial change to make. This work should be in beta3 due next
> week.
> The work includes dropping support for local repositories in favour of path
> based local charm and
My point is not to advocate for a specific solution but rather to suggest
that *any* sensible incremental approach will produce real results.
--Mark Ramm
On Mon, Mar 28, 2016 at 7:51 PM, David Cheney
wrote:
> On Tue, Mar 29, 2016 at 10:42 AM, Mark Ramm-Christensen
On Tue, Mar 29, 2016 at 10:42 AM, Mark Ramm-Christensen
(Canonical.com) wrote:
> Never a good time to stop feature work entirely and fix what amounts to a
> race prone set of tests.
>
>
> But I would advocate building in some practices to improve the situation
Never a good time to stop feature work entirely and fix what amounts to a
race prone set of tests.
But I would advocate building in some practices to improve the situation
incrementally:
- fixing one major issue per team per week
- promoting all issues which fail CI more than x times per
I agree with all the responses, I don't think it'd be helpful to move the
providers. It's our job to track the API changes. For most of the
upstreams, backwards incompatible changes are fairly infrequent.
If it's difficult to track API changes, perhaps it's the same for other
consumers of the
I'm a very strong -1 on this idea.
Providers are Juju specific, and the other libraries should focus on
exposing a useful Go API.
Tim
On 25/03/16 10:12, Eric Snow wrote:
> Perhaps we should move the implementation of some providers over to
> the repos for the projects with which the providers
I'll just note that we've had flaky tests for as long as I've been working
on Juju, and there's never a "good" time to fix them. :)
On Mon, Mar 28, 2016 at 11:48 AM Aaron Bentley
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2016-03-28 09:03 AM,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2016-03-28 09:03 AM, Katherine Cox-Buday wrote:
> Generally +1 on this, but I'm also intrigued by Martin's
> statistic... do we currently weight test failures by how likely
> they are to fail (i.e. how likely they are flaky)? That seems like
> it
These intermittently failing unit tests are often due to unreliable unit
tests, rather than problems in the code. As nice as it would be to not
have to retry tests (particularly unit tests), I'd much rather we spend our
precious resources on fixing bugs that are causing pain for our users.
There
Totally agreed: 2.0 is obviously the priority. I didn't think anyone was
talking about a short-term pivot.
On 03/28/2016 10:34 AM, Cheryl Jennings wrote:
> Addressing flaky tests is definitely a long term goal we should have.
>
> Given that we are aiming for beta4 next week, I'd rather our
Addressing flaky tests is definitely a long term goal we should have.
Given that we are aiming for beta4 next week, I'd rather our energies in
the short term are directed at fixing stakeholder bugs than fixing
intermittent failures that prevent us from releasing because we are no
longer retrying
While agreeing with the spirit of your email, Cheryl, I'd like to opine
that in the long-term fixing flaky tests will improve the code and help
to fix (and prevent!) bugs.
Put another way, flaky tests are indirectly causing pain for our users.
On 03/28/2016 10:24 AM, Cheryl Jennings wrote:
>
+1, don't retry... devs need to feel the pain in order to get proper
motivation to fix this stuff...
On Mon, Mar 28, 2016 at 9:03 AM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:
> Just wanted to say thank you 100x to all involved!
>
> On 03/24/2016 01:03 AM, Michael
Just wanted to say thank you 100x to all involved!
On 03/24/2016 01:03 AM, Michael Hudson-Doyle wrote:
> Hi,
>
> As of a few minutes ago, there is now a golang-1.6 package in
> trusty-proposed:
> https://launchpad.net/ubuntu/trusty/+source/golang-1.6 (thanks for the
> review and copy, Steve).
>
>
Generally +1 on this, but I'm also intrigued by Martin's statistic... do
we currently weight test failures by how likely they are to fail (i.e.
how likely they are flaky)? That seems like it would be a great metric
to use to decide which to fix first.
On 03/28/2016 01:29 AM, David Cheney wrote:
>
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,
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
22 matches
Mail list logo