Trivial bugs hurting progress

[Andrew Wilkins]

On Wed, Mar 4, 2015 at 9:53 PM, Dimiter Naydenov <
dimiter.naydenov at canonical.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On  4.03.2015 15:44, Martin Packman wrote:
> > On 04/03/2015, Andrew Wilkins <andrew.wilkins at canonical.com>
> > wrote:
> >> Hi all,
> >>
> >> Ian asked me to mail the list about a couple of bugs that managed
> >> to get past the bot; first so that we can all be mindful of these
> >> sorts of bugs, and second to highlight the fact that they could
> >> have been caught by the bot.
> >>
> >> The bugs were fixed in this branch:
> >> https://github.com/juju/juju/pull/1738 - random. iteration Map
> >> is
> >
> > This was being addressed as part of bug 1427149.
> >
> > <https://bugs.launchpad.net/juju-core/+bug/1427149>
> > <http://reviews.vapour.ws/r/1048/>
> >
> > Your patch means that branch now needed updating.
> >
> >> - invalid printf-style formatting will cause "go vet" to fail
> >
> > So, do we want to revisit making the bot fail on go vet errors?
> > That's trivial flip.
> >
> >> The bot is currently running (I think) Go 1.2. I'm running 1.4,
> >> Ian's running 1.3, and I'm sure Dave's running tip ;)  Go 1.3+
> >> made map iteration less deterministic, so these sorts of bugs are
> >> much more likely to occur after 1.2. It'd be good to either bump
> >> the compiler version to something more recent, unless we want to
> >> gate things on multiple compilers (maybe gc and gccgo, seeing as
> >> we currently use both).
> >
> > Curtis and I have talked about also doing a ppc64 test run as part
> > of the gating job, that gets us the map ordering stuff as a newer
> > go would, and other gccgo quirks covered as well. We don't want to
> > bump the compiler version yet I think, as we want to be able to
> > build with the trusty toolchain still, and not accidentally let in
> > regressions by depending on newer gos.
> If it's about catching map ordering issues, let's use go 1.3+ as an
> extra step, rather than gccgo, which is buggy and slow and randomly
> segfaults. It's likely we'll slow down merge gating considerably.
>

I'm guessing that these problems are not isolated to tests,
but also affect code in production. Seems like a problem
we should fix, rather than hide.

My main concern is slowing down the merge jobs. We've
all experienced merges taking an hour in the past, and it's
really quite painful. I don't have a feel for how slow the
gccgo-built tests will run, but I suspect slower than the gc
ones. I hope we can run them in parallel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150305/7f901ce6/attachment.html>