Not sure if this is in someone’s radar yet - the debian/changelog change misses
the date string for the last entry, causing the debian package build to break.
KC
On Dec 5, 2014, at 5:53 PM, David Nalley wrote:
> Hi All,
>
> I've created a 4.5.0 release candidate, with the following artifacts
FYI
During my regression testing of 4.5, I noticed a storage-related issue with
regards to VMware.
I had to correct it in be38b9706615d5ab0cc9959577b0fff9a36a9fc6.
On Mon, Dec 8, 2014 at 8:57 AM, Will Stevens wrote:
> Thank you. I have kicked off a system vm build to make sure everything is
>
Thank you. I have kicked off a system vm build to make sure everything is
working correctly. Lots of things in the queue though, so it may take a
while.
ws
*Will STEVENS*
Lead Developer
*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* t
merged
On Mon, Dec 8, 2014 at 4:46 PM, Daan Hoogland wrote:
> as a pragmatic programmer, yes. In light of the work we are starting
> on wednesday, no. I leave picking the answer as an excercise to the
> reader;)
>
> On Mon, Dec 8, 2014 at 4:43 PM, Will Stevens wrote:
>> I am not hosting a public
Fair enough. :) Just merge the branch this time and we will figure out
the details going forward. I think reducing the work for the person doing
the merge will help collaboration (even if the committer has to do a bit
more work), so I am open to how we do this...
ws
*Will STEVENS*
Lead Develo
as a pragmatic programmer, yes. In light of the work we are starting
on wednesday, no. I leave picking the answer as an excercise to the
reader;)
On Mon, Dec 8, 2014 at 4:43 PM, Will Stevens wrote:
> I am not hosting a public repo with the fix. I think a merge is the
> simplest way. A pull requ
I am not hosting a public repo with the fix. I think a merge is the
simplest way. A pull request is great for non-committers to contribute,
but I think it is a bit disjointed for committers who already have access
to create fix branches. Do you agree?
ws
*Will STEVENS*
Lead Developer
*CloudO
lgtm,
do i look for a pull request, or just merge?
On Mon, Dec 8, 2014 at 3:46 PM, Will Stevens wrote:
> We need to get my fix '[MERGE REQUEST] hotfix/4.5-7959'merged in to get the
> system vms building again. The building is currently broken because of a
> compatibility issues.
>
> This merge
We need to get my fix '[MERGE REQUEST] hotfix/4.5-7959'merged in to get the
system vms building again. The building is currently broken because of a
compatibility issues.
This merge should be made asap...
Cheers,
*Will STEVENS*
Lead Developer
*CloudOps* *| *Cloud Solutions Experts
420 rue Guy
few question about 4.5;
- which systemvm should we use? jenkins job build-systemvm-4.5 is a month
old.
- upgrade path seams damaged, previous bug CLOUDSTACK-8041 is
false, although I've never succeed to upgrade a system so far.
On Fri, Dec 5, 2014 at 11:07 PM, Pierre-Luc Dion wrote:
> The up
The upgrade path require a systemvm-template otherwise the database upgrade
fail, I've create this one: CLOUDSTACK-8041
Could it be possible to just look for the latest template to exist during a
db upgrade? with the current check, to upgrade from 4.2.1 require to have
the systemvm-template of 4.3
11 matches
Mail list logo
