Thanks everyone for the testing! I think the only relevant PRs to get merged are: https://github.com/jclouds/jclouds/pull/816 https://github.com/jclouds/jclouds/pull/790 https://github.com/jclouds/jclouds-labs/pull/188
Being the first one the most important one (I just have to rebase it to the latest master after having merged a PR that affects the AWS hardware profiles) Once the AWS PR is in, we should consider releasing 1.9.1. Would it be reasonable to release it between this Wednesday-Friday? If the other two PRs (and any eventual fix) can be included, the better, but I think it once the first one is in we'll be at a very good point to release 1.9.1. WDYT about scheduling the jclouds 1.9.1 release for Wednesday/Thursday/Friday? I volunteer to cut it. I. On 14 July 2015 at 21:19, Zack Shoylev <zack.shoy...@rackspace.com> wrote: > 1.9.x with my latest test fixes works fine with rackspace-cloudfiles-* and > rackspace-cloudservers-* live tests. > ________________________________________ > From: Zack Shoylev <zack.shoy...@rackspace.com> > Sent: Monday, July 13, 2015 8:13 PM > To: dev@jclouds.apache.org > Subject: Re: 1.9.1 pre-release testing > > I have some small test fixes, but haven't yet observed anything broken in > actual code. Still testing, though. > > ________________________________________ > From: Shrinand Javadekar <shrin...@maginatics.com> > Sent: Monday, July 13, 2015 3:48 PM > To: dev@jclouds.apache.org > Subject: Re: 1.9.1 pre-release testing > > I ran live tests against several blobstores with the 1.9.1-SNAPSHOT > branch and it worked just fine. Report attached. > > On Fri, Jul 10, 2015 at 11:05 AM, Shrinand Javadekar > <shrin...@maginatics.com> wrote: >> I'll run some live blobstore tests too next week and get back with the >> results. >> >> -Shri >> >> On Wed, Jul 8, 2015 at 2:31 PM, Ignasi Barrera <n...@apache.org> wrote: >>> Hi! >>> >>> Everything is in place to release 1.9.1, but I'd like to propose a >>> different approach this time. Usually we run the live tests against >>> each RC, but that means cutting new RCs to fix the important live >>> tests that fail, which is not an optimal procedure. >>> >>> I'd like to propose a "pre-release" period (a week?) to run the live >>> tests and fix them so we can have a smooth and great 1.9,1 release. It >>> would be great if we could coordinate some provider testing, as not >>> everyone knows the details of every provider (and not everyone has an >>> account in each one). >>> >>> Thinking about the most active contributors, it would be ideal if we >>> could split the work like: >>> >>> @nacx: aws-ec2, digitalocean and chef. >>> @abayer: Could you help with aws-ec2? >>> @danbroudy: google-compute-engine, google-cloud-storage. >>> @andreaturli: softlayer, docker. >>> @zack: rackspace-cloudservers, rackspace-cloudfiles. >>> @devjcsrj: can you give some love to ProfitBricks? >>> @ilgrosso: could you rune the live tests on Azure Compute? >>> @ccustine: would you be able to run the HPCloud Compute live tests? >>> @gaul: blobmaster! :) >>> >>> @all-mailing-list-subscribers: Any live test feedback on any provider >>> is very welcome, and PRs are very welcome too! >>> >>> Please, don't misunderstand this as an assignment of tasks! I'm just >>> thinking out loud about a way to coordinate work so we can test and >>> fix as many broken windows as we can, without duplicating efforts and >>> without converting it in a tedious task. Running and fixing live tests >>> (there shouldn't be many live tests failing) shouldn't be a tough >>> effort, and the benefits for the project are huge. >>> >>> >>> If there is an agreement, I'd propose a week of live test run&fix and >>> cut the 1.9.1 release on July 15-20. Does this sound like a good plan? >>> >>> >>> I.
