Re: A cautionary tale - mgo asserts

You had me at "ruins mongodb", actually just "ruins'. On Wed, Jun 8, 2016 at 9:04 PM, roger peppe wrote: > This is also relevant (but probably only for larger documents): > > https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/ > > Another reason to

Tech board agenda

Hello, Several times over this week there has been a call to do X to bring an issue to the tech board's attention. Sadly X has generally be "email", which in my mind is a shitty way of tabling issues for discussion. - Is there an agenda for the tech board? - Is there a way to add items for the

Re: Tech board agenda

On Wed, May 25, 2016 at 4:14 PM, Andrew Wilkins <andrew.wilk...@canonical.com> wrote: > On Wed, May 25, 2016 at 1:43 PM David Cheney <david.che...@canonical.com> > wrote: >> >> Hello, >> >> Several times over this week there has been a call to do

Re: Automatic commit squashing

at something is a fb > > > On Thursday, 16 June 2016, Horacio Duran <horacio.du...@canonical.com> > wrote: >> >> +1 on Dave's suggestion >> >> On Thursday, 16 June 2016, David Cheney <david.che...@canonical.com> >> wrote: >>> >>> Coun

Re: Automatic commit squashing

Counter suggestion: the bot refuses to accept PR's that contain more than one commit, then it's up to the submitter to prepare it in any way that they feel appropriate. On Thu, Jun 16, 2016 at 6:44 PM, roger peppe wrote: > Squashed commits are nice, but there's

Re: juju 2.0-alpha2 with lxd

Unless you are building Juju from source (which it doesn't look like you are) you don't need a Go compiler installed. On Mon, Feb 15, 2016 at 11:20 AM, Marco Ceppi wrote: > Right, it's not going to work: > >> It's not so much that you don't have golang installed, it's

Re: Go 1.6 is now in trusty-proposed

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

Re: I think master is leaking

If the test suite panics, especially during a tear down from a failure set up, you leak mongos and data in /tmp. I have a cron job that runs a few times a day to keep this leaking below a few gig. On Sat, Apr 9, 2016 at 8:13 AM, Horacio Duran wrote: > Hey, this is

Re: Go 1.6 is now in trusty-proposed

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

Re: Go 1.6 is now in trusty-proposed

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.

Re: Go 1.6 is now in trusty-proposed

7/03/2016, David Cheney <david.che...@canonical.com> 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

Re: Awful dependency problem caused by romulus

t; Really sorry about this Dave, I'd not realised just how much they relied on > each other. Surely there's an argument for romulus being merged into core? > > On Thu, May 19, 2016 at 8:55 AM, David Cheney <david.che...@canonical.com> > wrote: >> >> On Thu, May 19,

natefinch/npipe/v2 does not support the POSIX read/close semantics juju needs

TL;DR read issue https://bugs.launchpad.net/bugs/1581337 Thumper asked me to forward this to juju-dev for discussion http://reports.vapour.ws/releases/3964/job/run-unit-tests-win2012-amd64/attempt/2384 Fails because, npipe.Accept is blocking on accept goroutine 41 [syscall, locked to thread]:

Re: Awful dependency problem caused by romulus

s up > > On Thu, May 19, 2016 at 9:47 AM, David Cheney <david.che...@canonical.com> > wrote: >> >> I think that would be the best solution, I don't see how we can undo >> the dependencies between cmd/juju and romulus -- they're so tightly >> coupled they sho

Three CI builds in the last 48 hours have failed because launchpad had a lie down

We already have godeps which can take a set of vcs repos and flick them to the right revisions. Why does CI check out every single dependency from upstream every single time we do a build ? That introduces wc -l dependencies.tsv points of failure to every single CI run -- not to mention the

Re: Three CI builds in the last 48 hours have failed because launchpad had a lie down

e is some discussion > about changing that in a variety of ways (in a container in a long running > VM, etc), but it doesn't have a local copy to work from so it has to pull it > from upstream each time. > > John > =:-> > > > On Wed, May 18, 2016 at 8:05 PM, David Cheney <dav

Awful dependency problem caused by romulus

Hello, github.com/juju/juju/cmd/juju/commands: github.com/juju/romulus/cmd/commands: github.com/juju/romulus/cmd/setplan: < github.com/juju/juju/api/service: github.com/juju/juju/cmd/modelcmd: cmd/juju depends on the romulus repository, and the romulus

Re: Awful dependency problem caused by romulus

On Thu, May 19, 2016 at 4:30 PM, Casey Marshall <casey.marsh...@canonical.com> wrote: > On Wed, May 18, 2016 at 11:02 PM, David Cheney <david.che...@canonical.com> > wrote: >> >> Hello, >> >> github.com/juju/juju/cmd/juju/commands: >> github.com/j

Re: Awful dependency problem caused by romulus

On Thu, May 19, 2016 at 5:04 PM, roger peppe <roger.pe...@canonical.com> wrote: > On 19 May 2016 at 07:02, David Cheney <david.che...@canonical.com> wrote: >> Hello, >> >> github.com/juju/juju/cmd/juju/commands: >> github.com/juju/romulus/cmd/commands: >

Re: Please run go test -race before pushing code

Is the race detector build currently running and will it block landing ? On Wed, May 11, 2016 at 6:48 AM, Cheryl Jennings wrote: > Hey everyone, > > There have been some new races showing up in the CI race detector test. As > you're making your bug fixes, please

Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

What is the story with mongo ? It's constantly causing builds to fail CI because of it's complete shitness. I've heard that some people have moved to mongo 3.2 which fixes the problem, but as CI clearly is running the old rubbish version, this clearly isn't a problem which can be called fixed.

Re: go test github.com/juju/juju/state takes > 10 minutes to run

6, 2016 at 9:52 PM, David Cheney <david.che...@canonical.com> > wrote: >> >> Testing this package takes 16 minutes on my machine*; it sure didn't >> use to take this long. >> >> What happened ? >> >> * yes, you have to raise the _10 minute_ timeout

The mean time for a CI run has risen to 33 minutes

This got significantly worse in the last 6 weeks. What happened ? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: The mean time for a CI run has risen to 33 minutes

) On Wed, May 18, 2016 at 9:06 AM, Martin Packman <martin.pack...@canonical.com> wrote: > On 16/05/2016, David Cheney <david.che...@canonical.com> wrote: >> This got significantly worse in the last 6 weeks. What happened ? > > Either the juju tests are slower, or trusty on aw

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

What's the plan for mongo 3.2 ? Will we be required to support 2.x versions for the foreseeable future, or is there a possibility to make it a build or run time failure if mongo < 3.2 is installed on the host ? On Wed, May 18, 2016 at 9:01 AM, Martin Packman wrote:

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

2.4 iirc is EOL or near. The issue lies in the new storage > engine, which we could skip if mmapv1 ( the old one) wasn't also nearing EOL > I am currently on the phone but if You want more details I can dig up the > bug with details of what I am talking about. > > > On Tuesday, 17

go test github.com/juju/juju/state takes > 10 minutes to run

Testing this package takes 16 minutes on my machine*; it sure didn't use to take this long. What happened ? * yes, you have to raise the _10 minute_ timeout to make this test run. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

y 18, 2016 at 9:58 AM roger peppe <roger.pe...@canonical.com> > wrote: >> >> Out of interest, what's causing the 3.2 slowdown and what's the hack to >> speed it up again? >> >> On 18 May 2016 09:51, "Christian Muirhead" >> <christian.muirh...@can

<    1   2