Re: CI regressions will block merges

I'll fix 1342725 https://bugs.launchpad.net/juju-core/+bug/1342725. Sorry that one hasn't gotten in earlier. On Tue, Jul 29, 2014 at 2:09 PM, Horacio Duran horacio.du...@canonical.com wrote: Since $$fixes-1342937$$ is already committed I changed the state by hand in the bug report sorry I

Re: Please use gopkg.in for importing mgo

It's even easier than that. After doing go get and godeps -u, do a godeps -t and ensure the output matches dependencies.tsv. that will ensure that the actual dependencies that exist are the same as the ones we expect to exist. If they're different, something's wrong. This will require that

Re: getting rid of all-machines.log

=:- On Wed, Aug 6, 2014 at 4:13 PM, Tim Penhey tim.pen...@canonical.com wrote: On 06/08/14 16:11, Nate Finch wrote: all-machines.log seems both redundant and a ticking time bomb of disk space usage. Do we really need it? Can we drop it and maybe later schedule some time to use something like

Re: getting rid of all-machines.log

log. Gabriel On 08.08.2014 12:41, jaquilina wrote: there is an rsyslog for windows but obviously it requires a license http://www.rsyslog.com/windows-agent/ On 2014-08-06 16:42, Nate Finch wrote: Fair enough, I forgot about debug-log. Do we have an idea of how well aggregate logs

Re: getting rid of all-machines.log

, Aug 08, 2014 at 12:03:21PM -0400, Nate Finch wrote: [...] remote syslog and to the local file log, we wouldn't need to worry about log rotation of the local log screwing up what gets sent to the remote Do the standard rsyslog log rotation mechanisms not function well? On Windows, what about

Label: Ready For Review

I made a label on github.com/juju/juju (and coincidentally github.com/juju/utils) called Ready For Review. The reason for the label is that it is often difficult to figure out what branches are actually ready to be reviewed and which ones are really WIP and therefore aren't waiting to be reviewed.

multiple branches in the same repo

Some of our repos have multiple branches specifically for versioning via gopkg.in... it would be nice if the default branch in github were the current version, so when you go to look at the repo online, you're looking at the version that should be currently used. That way the activity etc will

running godeps in a test

I made this pull request: https://github.com/juju/juju/pull/495 It adds a test to run godeps in the root juju directory and ensures that the output matches dependencies.tsv. This will ensure there's a failing test if you're trying to run the tests and haven't run godeps -u to make your

Re: Label: Ready For Review

Hmm, that's a good point. This whole only owners can label stuff is annoying. I wonder if we should just make everyone owners. On Aug 11, 2014 5:59 PM, David Cheney david.che...@canonical.com wrote: What if the review needs the author to rework ? On Tue, Aug 12, 2014 at 7:55 AM, Nate Finch

Re: Label: Ready For Review

I hear this reviewboard thing is pretty cool... On Aug 12, 2014 5:05 PM, Tim Penhey tim.pen...@canonical.com wrote: On 12/08/14 10:30, Nate Finch wrote: Hmm, that's a good point. This whole only owners can label stuff is annoying. I wonder if we should just make everyone owners

Reviewboard

What's the status on this? I think this could really help our workflow. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Running godeps -u dependencies.tsv easily

Godeps should pull down new revisions, as of a month or so ago. You just need to do go get -u launchpad.net/godeps and you'll get the new revision. I don't believe it go-gets packages you don't already have, though. On Thu, Aug 14, 2014 at 11:27 AM, Dimiter Naydenov

Re: getting rid of all-machines.log

be +50 -150 than +75 -0. I don't know how to state it any simpler than that. On Thu, Aug 14, 2014 at 1:35 PM, Gustavo Niemeyer gustavo.nieme...@canonical.com wrote: On Thu, Aug 14, 2014 at 1:35 PM, Nate Finch nate.fi...@canonical.com wrote: On Thu, Aug 14, 2014 at 12:24 PM, Gustavo

First customer pain point pull request - default-hook

Just wanted to let people know that Moonstone is ramping up on the customer pain points, even ahead of the full spec and prioritization. I had talked to Jorge and Marco about what they thought was important, and they pointed out a couple of low hanging fruit. This was one of them. Many charms

Re: First customer pain point pull request - default-hook

on every possible hook (which is how charm writers will be implementing default-hook, IMO). John =:- On Sat, Aug 16, 2014 at 1:02 AM, Aaron Bentley aaron.bent...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-08-15 04:36 PM, Nate Finch wrote: There's new hook

Re: First customer pain point pull request - default-hook

On Wed, Aug 20, 2014 at 11:46 AM, Gustavo Niemeyer gust...@niemeyer.net wrote: People must be aware that there is a multitude of events dispatched to that one executable, potentially with events they do not expect, and they must be aware that by creating a different hook they will prevent

The tests now run godeps

In an effort to make sure that dependencies.tsv is actually correct, the tests in github.com/juju/juju now run godeps -t ./... and compare its output to dependencies.tsv. The test looks for godeps first in the $PATH, and then in the first $GOPATH/bin. If it is not found, it currently skips the

Re: The tests now run godeps

/src/pkg/errors godeps: no version control system found for /usr/lib/go/src/pkg/io godeps: no version control system found for /usr/lib/go/src/pkg/sync godeps: no version control system found for /usr/lib/go/src/pkg/sync/atomic ... ... On 21/08/14 05:18, Nate Finch wrote: In an effort

Re: The tests now run godeps

. It Just Works. On 21/08/14 10:12, Nate Finch wrote: What happens when you run godeps normally? It should ignore the std lib stuff, but I don't actually know how that's implemented. On Aug 20, 2014 8:02 PM, Ian Booth ian.bo...@canonical.com wrote: H. The test fails for me

Re: The tests now run godeps

/juju/go/bin/godeps On 21/08/14 10:20, Nate Finch wrote: All the test does is run godeps -t ./... It looks for godeps in the path first and then looks in gopath/bin. Do you maybe have a version in your path that is old? On Aug 20, 2014 8:15 PM, Ian Booth ian.bo...@canonical.com wrote

Re: The tests now run godeps

The point of the test is that developers *don't* run godeps. That's the problem. The original email noted that our dependencies.tsv in master was wrong. It's not the first time this has happened. I've also seen many developers wonder why things were broken when it was just godeps needing to be

changing the simplestreams filename format

Simplestreams generates files with names like this: http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/com.ubuntu.maas:daily:v2:download.sjson Unfortunately, the colons in the filename are illegal on Windows, which complicates getting tests running on Juju, and getting a

review request

I have a pull request https://github.com/juju/juju/pull/512 for using Lumberjack https://github.com/natefinch/lumberjack, the log rolling package I wrote, but the package itself hasn't been reviewed itself. I'd like to get it reviewed just like any other code we use in Juju. It's fairly simple

re-review request

https://github.com/juju/juju/pull/512 Recently rebased and some minor updates. Now that the team leads have decided to use this, I'd like to get it re-reviewed. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: review request

Roger was kind enough to review it. If others would like to, that's great, but it has at least had a good review by someone other than the author now :) On Thu, Aug 28, 2014 at 12:35 PM, Nate Finch nate.fi...@canonical.com wrote: I have a pull request https://github.com/juju/juju/pull/512

Re: Commented-out tests?

Git blame says ask Roger ;) 100% agree... don't leave in commented out code. If you feel you must, because you expect it to get uncommented very soon, then leave a very clear comment about why it was commented out and when it should get uncommented. But mostly just don't. On Fri, Aug 29, 2014

review PR 512

Someone who is allowed to give LGTMs please review PR 512 https://github.com/juju/juju/pull/512 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

A beginner's adventure in Charm authoring

I am working on writing a Juju charm to deploy the Discourse discussion forum software using their new docker image install process. This was my first charm, and I'm writing it in Go, because I like Go. This means I can't use the python charm helpers, but since I don't actually know what they

Re: A beginner's adventure in Charm authoring

given that we currently use the path, you can't have one charm for multiple series anyway. This would at least be better than what we have right now, and would be backwards compatible (older jujus would just require the old style local deploy and would ignore the extra series specification in the

Re: A beginner's adventure in Charm authoring

On Thu, Sep 4, 2014 at 3:26 AM, John Meinel j...@arbash-meinel.com wrote: ... Have I mentioned how much I hate YAML? Is it possible to write the config in JSON or something instead? JSON's no picnic either, but at least it doesn't care about white space. I'd recommend TOML, but I doubt

Github built-in side by side diffs finally exist

https://github.com/blog/1884-introducing-split-diffs Works a lot better than octosplit, too. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev

Please don't use bash when there are syscalls available

A user just complained that he can't bootstrap because Juju is parsing stderr text from flock, and his server isn't in English, so the error message isn't matching. https://github.com/juju/juju/blob/master/environs/sshstorage/storage.go#L254 Now, I think we all know that parsing error text is a

Important Blocking Bug

https://bugs.launchpad.net/juju-core/+bug/1367431 Someone from the down under crew, please take a look at this, since the US is currently at EOD or nearly so. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: Please don't use bash when there are syscalls available

...@canonical.com wrote: On Wed, Sep 10, 2014 at 4:45 AM, Nate Finch nate.fi...@canonical.com wrote: A user just complained that he can't bootstrap because Juju is parsing stderr text from flock, and his server isn't in English, so the error message isn't matching. https://github.com/juju/juju/blob

juju charm-sync and Windows?

How much do we care about charm development on Windows (both windows charms and development on windows machines)? The reason I ask is that Horacio is starting on the charm-sync task from the pain points spreadsheet (syncing the charm files local - unit during charm development debugging).

All reviews should be on reviewboard as of now.

http://reviews.vapour.ws/ Check your email for eric's step by step directions. It's not hard. Existing pull requests should be finished up on github, but from now on, all new pull requests should have reviews done on reviewboard. -Nate Tim Ian -- Juju-dev mailing list

Re: State should not depend on the API server

I have been in situations in past jobs where adding one field to one logical entity required changing the signature of a half dozen structures functions that were just copying data back and forth for little to no benefit. This is a pain in the ass, error prone, and should be avoided. One of the

Re: All reviews should be on reviewboard as of now.

So, in talking with Eric, he wanted to wait until Monday to get SSL working at least. He's going to the wipe this weekend and we can start using it Monday, and Eric will send out an email when it's done. On Thu, Sep 11, 2014 at 6:59 AM, Nate Finch nate.fi...@canonical.com wrote

Hangouts Supports Phone Calls

https://support.google.com/hangouts/answer/3187125?hl=en You can now make calls with Hangouts, calls to US Canada are free, which includes the Canonical conference call number. I find this to be really nice because it means I can use my headset as normal, and don't have to tie up my phone or

Re: Unit Tests Integration Tests

definitely not all in the same package. On Thu, Sep 11, 2014 at 11:29 AM, Matthew Williams matthew.willi...@canonical.com wrote: Hi Folks, There seems to be a general push in the direction of having more mocking in unit tests. Obviously this is generally a good thing but there is still

Re: Unit Tests Integration Tests

I like Gustavo's division - slow tests and fast tests, not unit tests and integration tests. Certainly, integration tests are often also slow tests, but that's not the division that really matters. *I want* go test github.com/juju/juju/... *to finish in 5 seconds or less. I want the landing bot

Re: logrotate configuration seems wrong

tl;dr: rsyslog sees 512,000,000 bytes and tells logrotate time to rotate! and logrotate sees less than 512MB and say nah, not big enough and rsyslog never writes the logs anymore because the file is too big. On Mon, Sep 15, 2014 at 10:07 AM, Wayne Witzel wayne.wit...@canonical.com wrote:

Re: ReviewBoard is now the official review tool for juju

Really, rbt pull -p is the only new step. All the rest of that is stuff you should already be doing as a normal part of writing code and making pull requests. I guess adding the link on the PR to the review is also a new step. If you really want to count that as a step. On Mon, Sep 15, 2014 at

Re: Someone please look at these bugs ASAP

Well, I could reproduce it with a charm from the charm store, so it's not just local charms. juju deploy cs:~natefinch/testcharm On Thu, Sep 18, 2014 at 5:02 AM, John Meinel j...@arbash-meinel.com wrote: On Thu, Sep 18, 2014 at 12:16 AM, Nate Finch nate.fi...@canonical.com wrote: First

Re: Is ReviewBoard a good thing?

There's one thing that hasn't been mentioned - reviewboard gives us a unified review queue. On github you need to look in 8 places to see all the stuff up for review, and anything not in juju/juju tends to get lost. This is really important since that can have a big effect on our velocity. I

Re: The Pros and Cons of ReviewBoard.

If we automate the creation of reviewboard reviews whenever a pull request is made, it would make it trivial even for outsiders. On Sep 19, 2014 5:01 PM, Matthew Williams matthew.willi...@canonical.com wrote: At the risk of opening a can of worms: Reviewboard doesn't have to be a barrier to

Re: Is ReviewBoard a good thing?

So, the automation between github and reviewboard seems necessary, so we should do that. It shouldn't be hard at all. Then the steps for submitting code will be: 1.) Submit a PR 2.) Get it reviewed on the automatically-created review. 3.) With a LGTM on the review, mark as $$merge$$ and the bot

HA UX Revamp

There was some feedback recently that the UX of Juju's HA implementation is not very good. I wrote up a doc[1] capturing the feedback and some solutions that were proposed during an informal meeting. The document is currently purely just about capturing information about the problem. It is not

don't forget the help

There's been at least a couple features which should have modified the juju command line help docs and did not . please remember to update the help docs, or no one will know the feature exists. Cases in point: juju help constraints was not updated when we added the instance-type constraint.

Re: Rsyslog imtcp issue

The state servers still use rsyslog, so you'd still have to be careful when deploying the charm to a state server. Probably it's best if we just fix the juju code to use its own daemon so as not to collide with charms that use it. The unit machines don't need rsyslog... unless you decide to turn

Azure US West having problems

This is a pretty major problem it *seems* like it must be Azure's fault, but it would be good to get more information about it. If anyone cares to investigate, here's the bug: https://launchpad.net/bugs/1383310 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or

how to update dependencies.tsv

We have a few windows dependencies that are not (and in some cases can not be) imported for the linux build. Luckily, the windows dependencies are a strict super set of the linux dependencies, so we can still use godeps to create dependencies.tsv, just by setting GOOS first, thusly (from the root

Re: how to update dependencies.tsv

and env vars we need to use this time? I'm also not 100% sure that we'll have even downloaded all the windows dependencies if they are a strict superset given that you are running go get on a Linux machine to start with. John =:- On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch nate.fi

Re: how to update dependencies.tsv

to build.Context) but it's not quite as easy as that. I should be able to fix it soon though. On 29 October 2014 10:10, Nate Finch nate.fi...@canonical.com wrote: We certainly should add a makefile target. I looked into it briefly yesterday, but didn't get far, as I haven't used makefiles since college

Re: how to update dependencies.tsv

Upstream and origin are very very common in the git world. Most any how to or stack overflow answer uses those by default. Origin is your repo and upstream is the repo you branched from. I started out doing it your way, Roger, since I agree that information does flow both ways, and naming my

Re: how to update dependencies.tsv

FWIW, I always branch off upstream/master. I don't have master synced to my repo, because it just seems like an extra step. Why not go straight to the source? On Oct 31, 2014 11:48 AM, Eric Snow eric.s...@canonical.com wrote: On Fri, Oct 31, 2014 at 2:11 AM, roger peppe

Re: reviewboard update

Awesome, nice work! On Nov 15, 2014 12:07 AM, Eric Snow eric.s...@canonical.com wrote: FYI, I was able to solve 3 reviewboard-github integration issues today: 1. pull requests for branches other than master now work (e.g. 1.21 backports) 2. no more hitting rate limits (5000 requests/hour

Re: Too space, or not two space

I vote for this is dumb and should not matter either way. On Nov 18, 2014 7:22 PM, John Weldon johnweld...@gmail.com wrote: +1 to the Third Way (and to single space) -- John Weldon On Tue, Nov 18, 2014 at 4:15 PM, Jesse Meek jesse.m...@canonical.com wrote: I take that as +1 from Dave.

m1.small rapidly becoming a scarce commodity

Here's the bug: https://bugs.launchpad.net/juju-core/+bug/1373516 I just heard from Jorge Castro that Robert (the person who filed the initial bug) is reporting that m1.smalls are going away even faster than we expected. This needs to get fixed ASAP. We need to change the ec2 provider to

Re: It's Friday, results are in on spaces issue

Oh come on. I thought there was agreement to just drop this? On Thu, Nov 20, 2014 at 3:26 PM, Jesse Meek jesse.m...@canonical.com wrote: http://reviews.vapour.ws/r/509/ -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/

Fwd: juju min version feature

moving to juju-dev On Mon, Dec 15, 2014 at 9:50 AM, Horacio Duran horacio.du...@canonical.com wrote: Hello everybody, for those of you who don't know me, I am Horacio Duran, I am part of Moonstone team on juju-core. All of you have been signalled as stakeholders on juju's min version

Re: commands

I'm so glad these are getting auto generated so they stay in sync. They should be consistent in style, we should choose capitalized or not and stick with it. I don't really care which. On Feb 3, 2015 7:08 AM, Nick Veitch nick.vei...@canonical.com wrote: Hello, I have just finished updating

Re: juju-core tests now running on Windows

Awesome! Thanks so much, Gabriel, Bogdan, and everyone else who worked on getting the tests running under Windows... this is really great. On Thu, Feb 19, 2015 at 9:13 AM, Gabriel Samfira gsamf...@cloudbasesolutions.com wrote: Hello folks, Thanks to Bogdan Teleaga's great work, juju-core

Re: GCE provider, successful bootstrap and deploy

Woo hoo! Nice work! On Jan 7, 2015 5:17 PM, Wayne Witzel wayne.wit...@canonical.com wrote: Eric Snow and myself have recently been working on the GCE provider. As of today, we have officially bootstrapped and deployed and setup a Wordpress instance and related MySQL instance. We are still

Re: Proposal: move package replicaset to its own GitHub repo

+100, thanks for doing this, Andrew! On Wed, Mar 25, 2015 at 6:16 AM, roger peppe roger.pe...@canonical.com wrote: This seems like a grand plan to me. On 25 March 2015 at 08:12, Andrew Wilkins andrew.wilk...@canonical.com wrote: I'd like to move the replicaset package to

Re: Is simplestreams spam worth having in the Log

make them trace On Wed, Apr 1, 2015 at 6:47 AM, John Meinel j...@arbash-meinel.com wrote: I've been noticing lately that everytime a test fails it ends up having a *lot* of lines about failing to find simplestreams headers. (this last test failure had about 200 long lines of that, and only 6

Re: kardianos/osext

So that expects import github... message is only supported in go 1.4 and later, so the 1.2 builders won't hit it. But yes, it means the person has moved their repo to github and wants you to use that one instead, which means we really should move our import, too. I believe that import is used by

please check your spam folders

I recently sent an email about backporting changes to repos that use gopkg, but I've gotten a report that it got send to spam, so please look for it there if you don't see it in your inbox. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: please check your spam folders

this was deliberate On Fri, Mar 27, 2015 at 1:57 PM, Nate Finch nate.fi...@canonical.com wrote: I recently sent an email about backporting changes to repos that use gopkg, but I've gotten a report that it got send to spam, so please look for it there if you don't see it in your inbox

serializing to json

FYI: Serializing a struct to json works without having to specify struct tags: type foo struct { Name string Age int } f := foo{ Bob, 40 } serializes (marshals) into { Name : Bob, Age : 40 } No struct tags needed. The only time you need struct tags is if you want to change

Re: serializing to json

can't typo no tag. Whatever, as long as we're doing it with a purpose, that's fine. On Mar 31, 2015 8:01 PM, Tim Penhey tim.pen...@canonical.com wrote: On 01/04/15 08:22, Nate Finch wrote: FYI: Serializing a struct to json works without having to specify struct tags: type foo struct

Joyent SSH key

There is a bug about us defaulting to uploading the user's private id_rsa ssh key to joyent as a part of bootstrapping a new server. This is obviously a bad thing. bug: https://bugs.launchpad.net/juju-core/+bug/1415671 However, the proposed solution (generate our own key and use that) doesn't

Re: adding placement directives for ensure-availability

is that they want to make their deployment more dense... with the option to replace a downed state server with a container on an existing machine in the environment. On Tue, Feb 24, 2015 at 12:40 PM, Gustavo Niemeyer gustavo.nieme...@canonical.com wrote: Hi Nate, On Tue, Feb 24, 2015 at 2:24 PM, Nate

Migrating imports away from code.google.com/p to golang.org/x

Just an FYI: As you've probably heard, code.google.com is going away. It'll be read-only for a year IIRC and then *poof*. Most of the packages from the go authors lived there (crypto, etc), but now will be maintained at golang.org/x. We'll be changing our imports to point at the new repos, so

backporting changes to packages that use gopkg.in

tl;dr: godeps overrides gopkg.in, so you can have godeps pin a commit from a different branch than gopkg.in is retrieving (i.e. make a release-number branch, like 1.22 and use godeps to pin commits from there, even if go get gopkg.in is getting a different branch). The long story: There was an

bug: apt-add-repository doesn't obey http-proxy

https://github.com/juju/juju/issues/1880 Adam Stokes brought this up in the cross team call today. Evidently it's actually a (really really old) Ubuntu bug, but of course it affects Juju when deploying on Ubuntu. This seems like the sort of thing that really should be fixed by Ubuntu, but if we

Re: previously valid amazon environment now invalid?

I mean, the control-bucket configuration value in the ec2 section of your environments.yaml is not required, and thus the error message is incorrect. On Tue, Apr 28, 2015 at 10:26 PM, Ian Booth ian.bo...@canonical.com wrote: On 29/04/15 04:41, Nate Finch wrote: No one seems to be answering

Re: previously valid amazon environment now invalid?

use 1.18, that seems like a lot of effort for little benefit. On Apr 29, 2015 6:29 PM, Michael Hudson-Doyle michael.hud...@canonical.com wrote: On 30 April 2015 at 07:40, Nate Finch nate.fi...@canonical.com wrote: We have done it before. As Roger said, there is/was a convention to do

Re: previously valid amazon environment now invalid?

We have done it before. As Roger said, there is/was a convention to do a three step process to deprecate old command line functionality. There's a big difference between what the command line looks like, and keeping compatibility with 1.18. We might want to preserve both, but they're not the

previously valid amazon environment now invalid?

If I do juju status with an unbootstrapped amazon environment, I get this: /home/nate/src/github.com/juju/juju master$ juju status ERROR Unable to connect to environment amazon. Please check your credentials or use 'juju bootstrap' to create a new environment. Error details: invalid EC2 provider

Re: previously valid amazon environment now invalid?

No one seems to be answering my actual question. That error message seems new. Is it? Either way, the error message is incorrect - control bucket is not required - and whatever is emitting that message needs to be fixed. On Apr 28, 2015 2:32 PM, Aaron Bentley aaron.bent...@canonical.com wrote:

Re: Resolving the same windows test failures again

Sorry for the lack of tests for that part of the code, I guess I added them for one and not the other. Note that I had actually been leaving that PR unmerged because I knew master was blocked. Sorry it got pushed in anyway, and caused problems. On Mon, May 4, 2015 at 7:20 PM, Martin Packman

like go test, but faster

Russ Cox has an experimental command called gt, which replaces the go test tool, and caches test output when you run it. The next time you run gt, if none of the files in a package have changed and none of the files of packages it depends on have changed, then gt will just reprint the cached

Re: Writing workers

Totally belongs on the wiki. On Mon, Jun 1, 2015 at 8:45 AM, John Meinel j...@arbash-meinel.com wrote: This is one of those things that should probably end up on the Wiki. Thanks for writing it up. John =:- On Thu, May 28, 2015 at 5:34 PM, William Reade william.re...@canonical.com

Re: Reminder: on June 15th, Go 1.4 will stop compiling things from code.google.com.

If you git clone the new repo into the old path on disk, that should just work with godeps etc. On Jun 2, 2015 8:15 AM, John Meinel j...@arbash-meinel.com wrote: What about old releases, etc? It seems like this is potentially an issue if we ever want to build an old release (for reference

Docs in-repo vs. github wiki

I just created a wiki page on the juju github repo to hold the information I typed up about running and writing CI tests, from my experience of the last week or so: https://github.com/juju/juju/wiki/ci-tests It occurs to me that much of the documentation that we have in files inside the repo

Pointer Receivers on Error() and String() methods

tl;dr: Don't. Use a value receiver. 99% of the time you can just delete the * on the receiver and it'll still work. If you really must use a pointer, please handle the case where you're called with a nil receiver. I spent most of today trying to understand why my new hook command was

Re: Pointer Receivers on Error() and String() methods

. On 20 August 2015 at 03:45, Nate Finch nate.fi...@canonical.com wrote: tl;dr: Don't. Use a value receiver. 99% of the time you can just delete the * on the receiver and it'll still work. If you really must use a pointer, please handle the case where you're called with a nil receiver

Re: New dependency

Just some context - Ben Johnson is an active member of the Go community, works in Go every day, and has several popular packages in use by many third parties. I would not worry about depending on his work from a quality or responsiveness aspect. As with John, I haven't looked at the exact code,

Re: A cautionary tale about go test -race -cover

Thanks for the info, Dimiter. That is almost certainly going to bite someone else at some point. On Thu, Jul 16, 2015 at 6:35 AM Dimiter Naydenov dimiter.nayde...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, tl;dr; When running $ go test -race -cover with

Re: Blocking bugs process

I think everyone's agreeing here, but maybe the wording just needs to be clarified somewhere to avoid confusion. It sounds like bugs which are assigned to a release do not block commits unless they are marked blockers. And blockers are determined by we wouldn't want *anyone* to upgrade to a

Re: Recurring fails on windows tests and the recent CentOS failure

I agree that this is the correct thing to do. However, it is error prone and non-obvious. Having a check that can ensure we do it correctly would definitely help avoid this problem in the future. Not needing to do it at all would be even better, but I understand that changing 100,000 lines of

Re: Recurring fails on windows tests and the recent CentOS failure

the cost of running all the setups and teardowns. Then we can do Roger's suggestion of ensuring that we don't forget to hook up setup and/or teardown. On Wed, Jul 15, 2015 at 3:31 PM William Reade william.re...@canonical.com wrote: On Wed, Jul 15, 2015 at 7:19 PM, Nate Finch nate.fi

Re: Blocking bugs process

Can you put this in the wiki? On Thu, Jul 9, 2015 at 6:33 PM Martin Packman martin.pack...@canonical.com wrote: The QA team have been trying to hammer out a clearer process over blocking bugs, and have put together the document below for discussion. We'll be handling bugs as described here

Re: Uniter tests for update-status hook - BLOCKER

On Mon, Jul 20, 2015 at 12:42 AM Tim Penhey tim.pen...@canonical.com wrote: Aside from all this work, it is becoming REALLY IMPORTANT that we stop writing terrible, wasteful, full integration type tests when what we really care about testing is some aspect of uniter internals. I know that it

Re: Uniter tests for update-status hook - BLOCKER

On Mon, Jul 20, 2015 at 10:57 AM roger peppe rogpe...@gmail.com wrote: On 20 July 2015 at 14:11, Martin Packman martin.pack...@canonical.com wrote: The logs are giant, the actual failure lines tend to be non-informative with the real cause several screens up in the log, multiple tests

Re: Uniter tests for update-status hook - BLOCKER

On Mon, Jul 20, 2015 at 3:05 PM roger peppe roger.pe...@canonical.com wrote: On 20 July 2015 at 19:41, Nate Finch nate.fi...@canonical.com wrote: You should be able to get to 80% code coverage (and near 100% logic coverage) without using anything outside your package. Shouldn't those

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

You're not selling me on this ;) On Tue, Oct 27, 2015, 4:01 PM Tim Penhey wrote: > I can't help but draw parallels to the plugin system. > > There was considerable resistance to adding the ideas of plugins to > Juju. It was added complexity that no one needed and

Re: On Call Reviewer Duties

Sounds good to me. On Wed, Oct 21, 2015, 6:39 AM Matthew Williams < matthew.willi...@canonical.com> wrote: > Hey Folks, > > I propose that on call reviewers as part of their job should also review > the issues list on https://github.com/juju/juju/issues and attempt to > triage anything that's

Re: Be very careful in assumptions in tests

I'll definitely +1 the need for gc.HasLen ... I've seen a ton of panics in tests if the code starts erroneously returning nil slices. Obviously this is less bad, since the tests still fail, but they're really ugly annoying failures. And +1000 to making tests that fail before fixing the code (or

<    1   2   3   >