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 b

Re: Juju is now on Github

On 04/06/14 01:40, Ian Booth wrote: On 04/06/14 09:54, Horacio Duran wrote: Thanks for the info Ian, you guys have done a wonderful job and have been very helpful during the day. You're welcome. The people who deserve special mention are Martin, Andrew, Curtis, and Aaron. There were a lot o

Re: moving bzr wip branch to git

Nice On Wed, Jun 4, 2014 at 2:08 PM, Jesse Meek 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 >

GitHub issues

The code's now on GitHub. What about issues? My understanding is that we will be sticking with Launchpad for bugs. One thing that I *really* like about integrated bug-tracking and source code management is linking between bugs and branches/commits. I find this most useful when looking back at old

Re: add dependencies step to github readme?

On 4 June 2014 11:02, Nate Finch 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 usi

Re: Juju is on github

WOOOT!!! On Tue, Jun 3, 2014 at 7:38 PM, Martin Packman wrote: > Juju development is now done on github: > > > > 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 b

Re: GitHub issues

On Wed, Jun 4, 2014 at 6:36 AM, Andrew Wilkins 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 Developme

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 ha

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 th

Re: Juju is on github

Hey Martin, On Tue, Jun 3, 2014 at 8:38 PM, Martin Packman wrote: > Juju development is now done on github: > > > > 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

Backup juju with/without interrupting juju

We currently have a backup plugin and a restore script that are entirely divorced from the rest of the codebase, and are therefore prone to breaking if core changes. Moonstone has been tasked with recreating backup and restore as first class citizens of juju. One of the complaints about the curre

Re: Backup juju with/without interrupting juju

On Wed, Jun 4, 2014 at 3:58 PM, Nate Finch 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 a

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 wrote: > On Wed, Jun 4, 2014 at 3:58 PM, Nate Finch > wrote: > ... > > Then the only cas

Re: Juju is on github

On 5 June 2014 06:58, Jorge Niedbalski 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:

Re: Juju is on github

Make it so On Thu, Jun 5, 2014 at 6:59 AM, Menno Smits wrote: > On 5 June 2014 06:58, Jorge Niedbalski > 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? > > > > -- >

Re: GitHub issues

On Wed, Jun 4, 2014 at 10:23 PM, Gustavo Niemeyer wrote: > 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 troubl

Re: GitHub issues

Actually the original plan was not to enable Github's issue tracker and continue using Launchpad's. Having 2 issue trackers is not optimal and will create too much management overhead and wasted effort. We are continuing to use Launchpad's milestones for scoping and planning releases etc and of cou

Re: Juju is on github

On Wed, Jun 4, 2014 at 5:39 PM, David Cheney wrote: > Make it so https://github.com/juju/juju/pull/21 Thanks. -- Jorge Niedbalski R. Software Sustaining Engineer @ Canonical Canonical Technical Services Engineering Team # Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544) # Phone: +5697667

Reviewing in progress work on Github

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 G

Re: Reviewing in progress work on Github

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 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 t

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 reque

Re: Reviewing in progress work on Github

You can keep updating a pull request as your work on a feature. Old diffs and comment are preserved. On nice feature is that old comments are hidden if the area of the code they reference is changed by a later diff. This link from the Github people themselves is light on detail but talks about how

Re: Reviewing in progress work on Github

Not trying to hijack this thread, but a suggestion for reviewing and CI testing. I have a hunch you guys already have something in place, but there is TRAVIS CI which integrates nicely with github repos through a yaml file. When a pull request is submitted it performs a build and then on the pull

Re: GitHub issues

The comment was made with the understanding that this was your original plan, and the point is to measure engagement before closing it down, or you'll never know whether it makes any difference for juju specifically. Also, isn't Launchpad able to track issues originally filed on other trackers? Th