Running CI tests locally.
Hi All, tl;dr bash script to run CI deploy job locally: https://github.com/waigani/juju-scripts/blob/master/ci.sh During the last sprint I showed a script which checks out the CI tools and runs the tests locally. The link to the script and slides have been in the sprint notes doc. As a few have asked for it, I'm sharing the link here. I've updated the script to make use of new flags and features added to the CI tools. The script comments give instructions on how to use it. I'll just give one example here: $ ci.sh --provider=amazon --current-juju-bin=/custom/version/juju/bin --keep-env --upload-tools --upgrade This uses my custom built Juju to bootstrap using my amazon config. It uploads and uses the local tools for bootstraping, deploys two services, adds a relation, then upgrades (incrementing the patch version by 1) - all on ec2. The environment is keep for inspection. ci.sh currently only runs the deploy job (bootstrap, deploy two services, add relation, destroy environment). From what I can see, this is the only job currently in the juju-ci-tools repository. I have been writing a JES deploy job (testing multiple environments). When this is ready*, ci.sh will be updated to run different jobs. * The JES deploy job script is all but done. Along the way, it has revealed bugs with JES which take priority over finishing the script. I do not want to push the JES job up until we get at least one clean pass. Cheers, Jess -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
bugs, fixes and targeting Juju versions
Hi All, tl;dr `git diff --no-prefix master diff.patch; patch -p0 diff.patch` is useful for landing bug fixes in different versions of juju. As a lot of us are currently bug hunting and needing to land fixes in multiple versions of Juju, I thought I'd share my process of doing that (maybe it's helpful?): So say you've branched master, let's call it bug-fix-master-branch, it's got your fix but you need to land it in 1.24. So branch 1.24, let's call it bug-fix-124, and do the following: # generate a diff of your changes that can be used with patch (--no-prefix master is the magic flag that generates the right format) (bug-fix-master-branch) $ git diff --no-prefix master diff.patch # don't add or commit, checkout the other branch (bug-fix-master-branch) $ git checkout bug-fix-124 # diff.patch is still there, unstaged. So use it to add the patch (bug-fix-124) $ patch -p0 diff.patch # do a sanity check (bug-fix-124) $ git diff # remove the patch file (bug-fix-124) $ rm diff.patch You've now got a bug-fix branch eligible for automatic merging targeting 1.24. Cheers, Jess -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: bugs, fixes and targeting Juju versions
Ah, even better. Now I can update my workflow :) On 05/05/15 13:43, Menno Smits wrote: cherry-pick will even grab the top commit of a branch if you give the branch name (presuming the fix is a single commit). For example: git checkout -b bug-fix-1.24 upstream/1.24 # create a branch for the fix in 1.24 git cherry-pick bug-fix-master-branch # pull the fix across There are various ways of grabbing multiple revisions too. And of course, as per Ian's recent email you should be targeting fixes to the lowest affected version and working forwards. So really in your example the fix should be made for 1.24 and the cherry picked onto a branch made from master. On 5 May 2015 at 13:15, Tim Penhey tim.pen...@canonical.com mailto:tim.pen...@canonical.com wrote: git cherry-pick does this as a git command. Tim On 05/05/15 13:03, Jesse Meek wrote: Hi All, tl;dr `git diff --no-prefix master diff.patch; patch -p0 diff.patch` is useful for landing bug fixes in different versions of juju. As a lot of us are currently bug hunting and needing to land fixes in multiple versions of Juju, I thought I'd share my process of doing that (maybe it's helpful?): So say you've branched master, let's call it bug-fix-master-branch, it's got your fix but you need to land it in 1.24. So branch 1.24, let's call it bug-fix-124, and do the following: # generate a diff of your changes that can be used with patch (--no-prefix master is the magic flag that generates the right format) (bug-fix-master-branch) $ git diff --no-prefix master diff.patch # don't add or commit, checkout the other branch (bug-fix-master-branch) $ git checkout bug-fix-124 # diff.patch is still there, unstaged. So use it to add the patch (bug-fix-124) $ patch -p0 diff.patch # do a sanity check (bug-fix-124) $ git diff # remove the patch file (bug-fix-124) $ rm diff.patch You've now got a bug-fix branch eligible for automatic merging targeting 1.24. Cheers, Jess -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: previously valid amazon environment now invalid?
Hi Nate, I looked into your bug. The default value for control-bucket was not being set. Here's a PR to fix: http://reviews.vapour.ws/r/1512/ Cheers, Jess On 29/04/15 06:41, Nate Finch wrote: 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 mailto:aaron.bent...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2015-04-28 11:42 AM, roger peppe wrote: The .jenv code was introduced prior to 1.16. How far back in time do we need to preserve compatibility? (genuine question) We need to support every mode of operation that 1.18 supported. Juju has a special exemption that allows minor releases, rather than micro/bugfix releases, to added to Ubuntu. But in order to use that exemption, new versions of Juju are supposed to be equivalent to a micro/bugfix release in terms of their compatibility. We had our own IS people upgrade to juju 1.20 from 1.18 and find that juju no longer worked. That's terrible. If transitioning to the new scheme is really an issue, it would be easy to write a very simple tool that would allow a .jenv file to be created from an existing environments.yaml entry. No, that's not the issue. We have workarounds. It's not supposed to break in the first place. Or is the issue perhaps not just one of backward compatibility, but that people are actually relying on this (ostensibly only-for-compatibility) functionality even for environments bootstrapped since 1.16? I don't know what ostensibly only-for-compatibility means. Yes we need to be compatible, and yes we need to stay compatible. Juju needs to be compatible with 1.18. As William Reade said, Thou Shalt Not Break Compatibility With 1.18. We Are Stuck With It. https://lists.ubuntu.com/archives/juju-dev/2014-July/003073.html Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVP9I7AAoJEK84cMOcf+9hYDwIAMXShmggDItLppDY3r4sKom3 6dyv2A3/vUHrRn2oeKeg1OdKnQpjxp0K7Tun4Q+QDSglEdA3w8Alm3vXPHXO2w73 YbYhdRxu5uEbGENtgokI8VPvfyD1eXJqLkpEHLs5NdR6G4ub/ws/kCQra1q8IyeK 3Msm68S1Xt6mUCRFVSOxJ5oIRCPaZKJCdUm4rsoZgkzxidMg77APOeChF39TMwbs sPAHiqEUf8tw0/LQJH972OaEuRAdiZRK/VVtHc8E/TTH4PoIy9xaN6zPpuxP6Xxq mEmIArIgyUPzKtQwudDfprxXo77TI6J9FvQSz4HWhmmMteQWnFU9U6jkJDdGDNI= =q20K -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Reviewboard - dependant branches
On 18/12/14 03:01, John Weldon wrote: Can someone remind me of the process for proposing branches that depend on another branch that is still in review? I know it's been discussed here and on irc before, but I don't recall the specifics. I think that the steps are: 1. Just propose the branch in github, which will trigger the automatic reviewboard integration 2. run some rbt command line invocation to update reviewboard with the upstream branch name I just don't recall the exact invocation for #2 and I don't want to experiment and muck something up :) rbt post -u --parent name-of-parent-branch Cheers, -- John Weldon -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Could someone double check this please
After upgrading from 1.20.12-trusty-amd64 to master (commit 2807fed7fad5619079c98ea105674d8a724d2e66), all unit logs continually spew errors similar to the following: // ~/.juju/local/log/unit-mysql-0.log 2014-11-26 09:09:07 ERROR juju.worker runner.go:219 exited uniter: failed to initialize uniter for unit-mysql-0: cannot initialize hook commands in 1.22-alpha1.1-trusty-amd64: symlink 1.22-alpha1.1-trusty-amd64/jujud 1.22-alpha1.1-trusty-amd64/action-fail: no such file or directory After upgrade, I am unable to destroy a service. Would someone be able to try the following on their box to confirm that I don't have something screwy on mine: # with old juju i.e. /usr/bin/juju juju switch local juju destroy-environment --force --yes local juju bootstrap juju deploy mysql juju deploy mediawiki juju add-relation mysql:db mediawiki:db # wait for env to be ready. Then with juju built from trunk: juju upgrade-juju --upload-tools juju destroy-service mediawiki If I run the upgrade again after I've issued the destroy-service command, the service then gets removed. I imagine the dying service is caught as the watcher has to reassess entities and states when it starts up after the upgrade. It's EOD here, I'll pick up on this in the morning. Thank you in advance. Jess -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
It's Friday, results are in on spaces issue
http://reviews.vapour.ws/r/509/ -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: It's Friday, results are in on spaces issue
It got three ship its and has just landed. Nate has called for team leads to re-vote on it. From my perspective, the team voted, it's documented and we are done. Even if the decision changes to it does not matter, it is still a decision to put in the style guide. I'm now signing out of this issue/discussion. On 21/11/14 09:40, Tim Penhey wrote: I'm +1 on dropping it. On 21/11/14 09:29, Nate Finch wrote: 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 mailto:jesse.m...@canonical.com wrote: http://reviews.vapour.ws/r/__509/ http://reviews.vapour.ws/r/509/ -- Juju-dev mailing list Juju-dev@lists.ubuntu.com mailto:Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/__mailman/listinfo/juju-dev https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Too space, or not two space
I'm coming across double spaces after a full stop in comments. Some consider this an error, others an intentional style that makes the comment cleaner to read. Yes, it's a minor point but in the name of consistency and avoiding future review ping pong on the issue, I'm calling for a vote: Should we have a single space after full stops in comments? http://xkcd.com/1285/ Please reply +1 for yes to one space, -1 for no to one space. I'll tally up votes on Friday and update our style guide accordingly. My vote: +1 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Too space, or not two space
I take that as +1 from Dave. On 19/11/14 13:13, David Cheney wrote: To quote Butterick's http://practicaltypography.com/one-space-between-sentences.html I think two spaces look better so that’s what I’m going to use. I’m telling you the rule. If you want to put personal taste ahead of the rule, I can’t stop you. But personal taste doesn’t make the rule evaporate. It’s like saying “I don’t like how subjunctive-mood verbs sound, so I’m never going to use them.” On Wed, Nov 19, 2014 at 11:10 AM, Jesse Meek jesse.m...@canonical.com wrote: I'm coming across double spaces after a full stop in comments. Some consider this an error, others an intentional style that makes the comment cleaner to read. Yes, it's a minor point but in the name of consistency and avoiding future review ping pong on the issue, I'm calling for a vote: Should we have a single space after full stops in comments? http://xkcd.com/1285/ Please reply +1 for yes to one space, -1 for no to one space. I'll tally up votes on Friday and update our style guide accordingly. My vote: +1 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
reviewboard - most recent diff by default?
Is possible and preferable to show the most recent diff by default? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Is ReviewBoard a good thing?
On 20/09/14 02:34, Eric Snow wrote: On Thu, Sep 18, 2014 at 6:19 PM, Jesse Meek jesse.m...@canonical.com wrote: We moved to GitHub in the hope of lowering the bar to contributors outside the team. GitHub is *the* platform and process for open source software. This was the logic behind the move. It was deemed to have the most mindshare and we sacrificed our prefered platform and process to be part of that mindshare. We are now leaving that 'main stream' process to something that suits the tastes of our team - ReviewBoard. This adds friction for new contributors (friction everyone has experienced this week). This is mostly a consequence of moving to a new tool. Not only are we still getting used to a new tool, we are also learning what pain points it introduces. We have not had a chance yet to find reasonable solutions (or determine that the concerns are practically insurmountable). My belief is that the main concerns are solvable in the short term (github and reviewboard have good APIs and reviewboard is super extendable). If we value our preferred methods of reviewing over keeping to a well known process for outside contributors, the best process was launchpad + rietveld. Shouldn't we simply return to that. If we ditch ReviewBoard, let's just go back to GitHub. However, I don't think we should ditch ReviewBoard yet. It is way to early to make that kind of decision. Let's give it a chance and take this up in Brussels. I was not seriously suggesting we return to lp. Using ReviewBoard reintroduces what we gave up with lp: both the good (tooling that addresses pain points) and the bad (not a well known/widely adopted process of contributing). In this regard, using ReviewBoard is akin to returning to lp. It is not a question of does ReviewBoard address our pain points nor is it a question of is this just teething?. Both valid questions in their own right, but they miss the point. Is raising the bar to outside contributors necessary and justified? Is it necessary? Many of us have addressed our own pain points with GitHub already. I use browser plugins, git hooks and scripts to augment my workflow. Yet I can work along side the first time contributor that has nothing more than git and a GitHub account. What pain point necessitates raising the bar to contributors? Is it justified? Given such a pain point exists, does solving it justify *forcing* a new tool on a developer? This is the decision we are making and it is not just for 'us' the team. It is for our would-be external contributors. The ones that we moved to GitHub for. Considering we have been successfully using GitHub for several months now, using reviewboard is not a necessity. Obviously, I will go with whatever the team decides, but I'm concerned that we have moved to reviewboard without considering that it undermines (as far as I can see) our primary reason for using GitHub. I agree that reviewboard as we currently have it now adds extra work to our workflow. Not only does this impact the juju team, but it does add a stumbling block to more community involvement. However, my firm belief is that the real pain points are addressable in the short term. Let's give it a chance. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Is ReviewBoard a good thing?
We moved to GitHub in the hope of lowering the bar to contributors outside the team. GitHub is *the* platform and process for open source software. This was the logic behind the move. It was deemed to have the most mindshare and we sacrificed our prefered platform and process to be part of that mindshare. We are now leaving that 'main stream' process to something that suits the tastes of our team - ReviewBoard. This adds friction for new contributors (friction everyone has experienced this week). If we value our preferred methods of reviewing over keeping to a well known process for outside contributors, the best process was launchpad + rietveld. Shouldn't we simply return to that. Considering we have been successfully using GitHub for several months now, using reviewboard is not a necessity. Obviously, I will go with whatever the team decides, but I'm concerned that we have moved to reviewboard without considering that it undermines (as far as I can see) our primary reason for using GitHub. Jess -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Testing the API server
Hi List,
The API server client tests have a new suite, serverSuite, which allow
you to test the api server methods without having to go through the api
client.
This is how to use it:
// old way
func (s *clientSuite) TestSomething(c *gc.C) {
...
// calls via api/client
err := s.APIState.Client().EnvironmentSet(args)
...
}
// new way
func (s *serverSuite) TestSomething(c *gc.C) {
...
// does not touch api/client
err := s.client.EnvironmentSet(args)
...
}
I also added PatchClientFacadeCall to api/export_test.go which allows
client side testing without touching the API server:
https://github.com/juju/juju/blob/master/api/export_test.go (see
TestShareEnvironmentExistingUser for an example)
Andrew just landed PatchFacadeCaller:
https://github.com/juju/juju/blob/master/api/base/testing/patch.go.
https://github.com/juju/juju/blob/master/api/base/testing/patch.go
Which is a generic Facade patcher that requires setup in export_test.go
to get access to the private facade instance (see provisioner tests for
an example). PatchClientFacadeCall can be used now, but I will be
refactoring it soon to leverage PatchFacadeCaller so we have a
consistent approach across the codebase.
Cheers,
Jess
https://github.com/juju/juju/blob/master/api/base/testing/patch.go
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Copyright information in headers
I've been asking for updates in my reviews. I'm happy to stop if the consensus is we don't need to. Once we get an agreement on policy, let's put it in the style guide. On 04/09/14 09:55, Gustavo Niemeyer wrote: I suggest not updating it. Updates on the same line will conflict, and cause completely unnecessary headaches. These files are under revision control, so there are better proofs of when it was changed than just that header. Then, in a decade or two, if somebody cares, update them all at once. On Wed, Sep 3, 2014 at 6:50 PM, Ian Booth ian.bo...@canonical.com wrote: Hi folks The question recently came up in reviews as to whether we should be updating the date in the copyright statement in the file header when we make a change to the code in that file. I sought clarification from Robie Basak, who previously had provided input on licensing issues and compliance for getting Juju included in trusty. Below is what he said. TL;DR; It doesn't really matter, we just need to agree on a policy. It is suggested though that we do update the date when we make a change. Agree? snip What's our policy for dates in copyright headers? // Copyright 2012, 2013 Canonical Ltd. // Licensed under the AGPLv3, see LICENCE file for details. From the point of view of acceptability for Ubuntu, it doesn't particularly matter, and I don't believe it'll cause any issue for us whatever you do here. I'll certainly be happy to upload whether or not you update the date. I'll try to explain my perspective on this, but I'm not entirely confident that there isn't something I'm missing for the broader picture, so note that I Am Not A Lawyer, etc. For the above, do we need to add 2014 if we modify the file this year? Or is the date just meant to be the year the file was first published? I think it's meant to be the sum of all the copyright claims on the file. So if you add some new code, you have a copyright claim on the new code in the newer year in which you made it. AIUI, the purpose of the date is that since copyright expires (theoretically, anyway), updating the date updates the copyright claim, which would give us more control in the (eventual) event that copyright expires. In practice, IMHO this is never going to matter since nobody is going to care about the copyright on a piece of software that is that old anyway. But I suppose laws could change, so the right thing to do would be to add a new year whenever you make a change in a new year on a per-file file basis. BTW, it's common to fold 2012, 2013, 2014 to just 2012-2014. But I don't particularly care for upload purposes. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
And now for my next trick ...
After checking the import grouping I became curious as to what else I
could check. So, while on holiday, I wrote another script to check if
errors are being discarded. It uses the ast package to check for both
assignment statements, where a value of type error is being assigned
to a variable of name _ and non-assignment expression statements that
return at least one value of type error.
The results were disappointing, for me, but good for Juju. It only
picked up one case:
environs/config.go:48-51
p, _ := Provider(kind)
if p == nil {
return fmt.Errorf(environment %q has an unknown provider type
%q, rawEnviron[name], kind)
}
So, not a huge revelation, but good to know we are not discarding errors
at least. :)
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
And now for my next trick ...
After checking the import grouping I became curious as to what else I
could check. So, while on holiday, I wrote another script to check if
errors are being discarded. It uses the ast package to check for both
assignment statements, where a value of type error is being assigned
to a variable of name _ and non-assignment expression statements that
return at least one value of type error.
The results were disappointing, for me, but good for Juju. It only
picked up one case:
environs/config.go:48-51
p, _ := Provider(kind)
if p == nil {
return fmt.Errorf(environment %q has an unknown provider type
%q, rawEnviron[name], kind)
}
So, not a huge revelation, but good to know we are not discarding errors
at least.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Thoughts to keep in mind for Code Review
+1 on annotations. Would a tag be useful to disambiguate from comments intended to stay in the PR? On 25/06/14 16:20, John Meinel wrote: An interesting article from IBM: http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/ There is a pretty strong bias for we found these results and look at how our tool makes it easier to follow these guidelines, but the core results are actually pretty good. I certainly recommend reading it and keeping some of it in mind while you're both coding and reviewing. (Particularly how long should code review take, and how much code should be put up for review at a time.) Another trick that we haven't made much use of is to annotate the code we put up for review. We have the summary description, but you can certainly put some inline comments on your own proposal if you want to highlight areas more clearly. John =:- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
jujubot build #
Would it be much work to get the jujubot to report the build number when it accepts a merge request? i.e. Status: merge request accepted. Build#:125, Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju Would it be something that others would find useful? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
$ juju switch --format
I have a branch proposed that displays extra environment information when the --format flag is used with switch e.g: $ juju switch local --format yaml environ-name: local previous-environ-name: ec2 state-servers: - example.com - kremvax.ru username: joe There is some debate over this. Roger has summarised the key issues well in his review comment: I think this is a bit odd. In every other command AFAIK, choosing a format does not affect the actual information displayed, just the format that it's printed in. Why are we printing all this info with the switch command anyway? Personally I'd think that a new command was warranted here, perhaps juju current, or juju show or juju info. My first implementation used a --env-info flag, but through review this was deemed to be not user friendly. I think the UX needs some discussion. Addressing the concerns, can we not: $ juju switch [env] $ juju info # display env info of env user just switched into Providing the previous-environ-name would take some extra thought, or if this is not important we could drop it. Are there good reasons not to do this? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
add dependencies step to github readme?
After running: go get -v github.com/juju/core/... I got: ../../github.com/juju/core/testing/imports.go:17: undefined: github.com/juju/testing.FindImports which was resolved by updating my dependencies with godeps. Shouldn't we add godeps -u dependencies.tsv as a step in the readme? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
moving bzr wip branch to git
So the command that worked for me (thanks for the help Tim) was: ~/go/src/github.com/juju/juju$ (cd ~/go/src/launchpad.net/juju-core bzr diff --color=never -r ancestor::parent) | patch -p0 --merge -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
