Re: Resolving the same windows test failures again

On Tue, May 5, 2015 at 7:20 AM, Martin Packman wrote: > There was some confusion about the regression to the windows test > failures on trunk. > > > > Partly my fault, Curtis initially looked at the 1.24 branch and I > looked at trunk, and each

Re: bugs, fixes and targeting Juju versions

Yes, cheery pick is something I use all the time, as it fills out the PR in the latter branches with a nice commit message based on the original and also includes the original PR from which the commit was first done. On 05/05/15 11:45, Jesse Meek wrote: > Ah, even better. Now I can update my workf

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 wr

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 fi

Re: bugs, fixes and targeting Juju versions

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 va

Re: bugs, fixes and targeting Juju versions

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

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

Resolving the same windows test failures again

There was some confusion about the regression to the windows test failures on trunk. Partly my fault, Curtis initially looked at the 1.24 branch and I looked at trunk, and each branch has a different issue. Here's what I've just done to diagnose

Re: Do not land code on blocked branches

So I believe you can already switch to how the Juju client does it today (call AddCharm before you call ServiceDeploy), just that we can't require you to do so. John =:-> On Mon, May 4, 2015 at 7:56 PM, Richard Harding wrote: > Thanks for the update. I've closed the bug for now and we'll reopen

Re: Do not land code on blocked branches

Thanks for the update. I've closed the bug for now and we'll reopen an issue to update to the latest api version once that's changed. On Sun, 03 May 2015, John Meinel wrote: > Just to follow up one small point, Rick. The reason Juju has to fix the API > and restore the old behavior is because eve