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
> (Canonical.com) wrote:
>
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
> incrementally:
>
> fixing one major
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'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, Katherine Cox-Buday wrote:
> >
-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 energie
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 t
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:
> Thes
+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 Hudson-Doyl
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, 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
On 24/03/2016, Ian Booth wrote:
>
> Not yet. The builders and test infrastructure all need to be updated, and
> the package needs a week to transition out of proposed.
I'd also encourage people to look again at the go 1.5/1.6 unit test
intermittent failures, as we're still often doing multiple ru
On 24/03/16 22:01, Nate Finch wrote:
> Does this mean we can assume 1.6 for everything from now on, or is there
> some other step we're waiting on? I have some code that only needs to
> exist while we support 1.2, and I'd be happy to just delete it.
>
Not yet. The builders and test infrastructur
Does this mean we can assume 1.6 for everything from now on, or is there
some other step we're waiting on? I have some code that only needs to
exist while we support 1.2, and I'd be happy to just delete it.
On Thu, Mar 24, 2016, 4:07 AM Tim Penhey wrote:
> Awesome news Michael.
>
> Thank you fo
Awesome news Michael.
Thank you for all your work on this.
Tim
On 24/03/16 19:03, 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, St
OMFG that is the best news. We can finally get the Juju LXD provider working
properly on trusty :-D
And first class support for all architectures etc :-D
And no more chasing gccgo issues :-D
Thanks Michael and whoever else helped make this possible.
On 24/03/16 16:03, Michael Hudson-Doyle wrote:
Thanks :)
Oh yeah, https://bugs.launchpad.net/ubuntu/+source/golang-1.6/+bug/1536882
currently has the verification-needed tag -- it would be awesome if
someone (tm) could do some package builds against this version of the
package -- would seem to me to be the ideal SRU verification for
getting th
THIS IS FANTASTIC NEWS MICHAEL!
On Thu, Mar 24, 2016 at 5:03 PM, 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).
>
> One diffe
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).
One difference between this and the package I prepared earlier is that
it does not install /usr/bin/go but rather /usr
23 matches
Mail list logo