Re: add dependencies step to github readme?
So there is a request up to do this, which we can move forward on, but I'm not personally convinced. If only because it isn't actually a simple drop-in replacement. Specifically, Godeps defaults to copying all of the dependencies into Godeps/_workspace, and then wants you to actually change your commands to godeps go test ./... etc. If I read it correctly, essentially Godeps wants to control your GOPATH rather than using a shared GOPATH. I'm not a big fan of having an extra copy of my dependencies in a hidden directory (since then I'm not actually sure what code is being run at any given time.) We *can* switch, but it means we should be prepared to switch over how we run code, deal with dependencies, etc. John =:- On Wed, Jun 4, 2014 at 5:28 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: Agreed, we should improve that. Sounds like we're going to change over to using godep instead of godeps, so we should update this at the same time. Cheers, Andrew On Tue, Jun 3, 2014 at 6:33 PM, Jesse Meek jesse.m...@canonical.com wrote: 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 -- 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
Re: add dependencies step to github readme?
There's an option to pass -copy=false which won't copy over the sourcecode. I don't think we need to keep the external sourcecode in our repo, given that all our external dependencies are controlled by canonicalers (and we have N copies of the dependencies where N = the number of people who have build juju recently). Definitely we should try it out and see if it fixes any of the niggles we have with godeps. On Wed, Jun 4, 2014 at 2:16 AM, John Meinel j...@arbash-meinel.com wrote: So there is a request up to do this, which we can move forward on, but I'm not personally convinced. If only because it isn't actually a simple drop-in replacement. Specifically, Godeps defaults to copying all of the dependencies into Godeps/_workspace, and then wants you to actually change your commands to godeps go test ./... etc. If I read it correctly, essentially Godeps wants to control your GOPATH rather than using a shared GOPATH. I'm not a big fan of having an extra copy of my dependencies in a hidden directory (since then I'm not actually sure what code is being run at any given time.) We *can* switch, but it means we should be prepared to switch over how we run code, deal with dependencies, etc. John =:- On Wed, Jun 4, 2014 at 5:28 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: Agreed, we should improve that. Sounds like we're going to change over to using godep instead of godeps, so we should update this at the same time. Cheers, Andrew On Tue, Jun 3, 2014 at 6:33 PM, Jesse Meek jesse.m...@canonical.com wrote: 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 -- 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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: moving bzr wip branch to git
Nice On Wed, Jun 4, 2014 at 2:08 PM, Jesse Meek jesse.m...@canonical.com wrote: 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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: add dependencies step to github readme?
On 4 June 2014 11:02, Nate Finch nate.fi...@canonical.com wrote: There's an option to pass -copy=false which won't copy over the sourcecode. This *should* work, but currently doesn't because godep doesn't support some of its functionality (the sandbox box) for bzr dependencies. That should not stop it working when using godep restore, so I've submitted a PR to godep to fix that (https://github.com/tools/godep/pull/89). With that fix, godep does pretty much what we need (but see below). I don't think we need to keep the external sourcecode in our repo, given that all our external dependencies are controlled by canonicalers (and we have N copies of the dependencies where N = the number of people who have build juju recently). Agreed, mostly. All our external dependencies are not actually controlled by canonicalers, but I don't think that changes the point. For less well controlled dependencies (github.com/binary132/gojsonschema springs to mind) we should perhaps consider forking the project into github.com/juju. Definitely we should try it out and see if it fixes any of the niggles we have with godeps. The main niggle there AFAIK is the fact that godeps doesn't know how to download new dependencies. I could fix that, but I'd prefer to move towards using a tool that's not used by us only. Godep is by no means perfect though. It's quite slow as it updates dependencies on a package-by-package basis rather than a repo-by-repo basis. It also does not complain if one of the repositories you're restoring has local changes, which could result in some awkward situations. Hopefully I'll be able to get some PRs to godep approved that will help there. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Juju is on github
WOOOT!!! On Tue, Jun 3, 2014 at 7:38 PM, Martin Packman martin.pack...@canonical.com wrote: Juju development is now done on github: https://github.com/juju/juju See the updated CONTRIBUTING doc for the basics. To land code you want the magic string $$merge$$ in a comment on the pull request so the jenkins bot picks it up. Note that the bot is currently taking around three times as long to run the tests, as we can't run suites in parallel due to mongo test flakiness. We'll work on improving that, but feel free to find and fix slow tests while you wait. :) As a team we're going to have some pain and discovery this week, please share any git tips and information you find useful as you go along. Thanks! Martin -- 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
Re: GitHub issues
On Wed, Jun 4, 2014 at 6:36 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: What are our options? Is it simplest just to disable GitHub issues, and have the lander pick up fixes lp:NN and add a comment to the bug in Launchpad? I think this is the easiest path. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: GitHub issues
I would keep them around for a while and try to observe how the community reacts to the availability. If people don't care, then just closing it sounds fine. If you start to get engagement there, might be worth going over the trouble of supporting users that live in that ecosystem. My experience has been that I got significantly more engagement, including bugs, once moving over projects to github. On Wed, Jun 4, 2014 at 10:13 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Wed, Jun 4, 2014 at 6:36 AM, Andrew Wilkins andrew.wilk...@canonical.com wrote: What are our options? Is it simplest just to disable GitHub issues, and have the lander pick up fixes lp:NN and add a comment to the bug in Launchpad? I think this is the easiest path. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Membership changes on github
I have changed our memberships on teams under the github juju organisation, to limit commit access to the juju branch to the landing bot. Sorry for the extra email kipple from this. Everyone is now a member of @juju/hackers and everyone except team leads have been removed from owners. Branches that have gated landings have @juju/bots only as collaborators. Branches we still need to test and merge manually have @juju/hackers as collaborators. The juju-gui project is both - you guys may want to switch to bot only. Owners can still do everything. This means yes, team leads, you can still corrupt the central repository if you do bad things with git. As a side effect, you'll notice you've been subscribed to lots of repositories you may not have been previously. You can go and unwatch any you don't want to receive email about, just go to the page (such as https://github.com/juju/jenkins-github-lander) and on the 'Unwatch' dropdown select either Not watching or Ignoring. There are still a few issues with the current setup - most of us now can't do useful things like add a new repository under the juju namespace, we'll need to ask our team lead to do it instead. We also can't bypass the bot if needed, and team leads lack a safety net by default. One option would be to create a role account, jujuowner, remove *everyone* from owners but that, and share the credentials to that account. Would this be preferable to the current setup? Martin -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Backup juju with/without interrupting juju
I'm not sure I understand the distinction, Curtis. Backing up the state data in an HA environment is what I was talking about for large environments. On Wed, Jun 4, 2014 at 4:12 PM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Wed, Jun 4, 2014 at 3:58 PM, Nate Finch nate.fi...@canonical.com wrote: ... Then the only case that is really a problem is large environments which are not using HA, which should be something we discourage, and uninterrupted backup can be a way to show the benefits of HA. There is one other scenario. A backup and restore of a HA env. We support this as a final fallback for cases where disaster strikes all state-servers. We test that his can always be done. CI does see the downtime. I think this is acceptable since a human chooses to bring down state-server and none of the other services running in the environment are affected. In the future, when charms can report the health of services, consumers of health data may have some sense of downtime. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- 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
Re: Juju is on github
Make it so On Thu, Jun 5, 2014 at 6:59 AM, Menno Smits menno.sm...@canonical.com wrote: On 5 June 2014 06:58, Jorge Niedbalski jorge.niedbal...@canonical.com wrote: 2cents: Why not rename the CONTRIBUTING file to CONTRIBUTING.md so it will be rendered as a markdown file by github? That seems sensible. Any objections? -- 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
Re: Reviewing in progress work on Github
You can, but then you loose any previous comments and history on the previously work in progress pull request. With Launchpad, you could just flip the status on the merge proposal and all the comments would be retained. On 05/06/14 13:38, John Meinel wrote: Can't you just create a new Pull request when it is finally ready? John =:- On Thu, Jun 5, 2014 at 7:25 AM, Ian Booth ian.bo...@canonical.com wrote: One of the many things I miss now that we have moved to Github/git is the ability to put up a merge proposal with in-progress work, allowing collaboration on the implementation as it evolves etc. Launchpad supported this nicely, as it didn't spam people with emails for wip mps etc. I don't think Github supports this concept. Perhaps a way around it is to do a pull request against one's forked copy of the main Juju repo. That way, people can still easily see your work, but without the general spam. Sadly, it doesn't allow the pull request to then be re-targetted to the Juju repo when ready to be reviewed for real. Or does it? Does anyone have any better ideas how 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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
