You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Phillips <ap...@qrmedia.com> on 2014/01/22 19:36:38 UTC
Roadmap for 1.8.0 and beyond?
Picking up from discussions last year about our release cadence
[1]...would it make sense to try to put together a draft backlog for
1.8/2.0 and beyond, to see what development capacity we're likely to
have and hence what can realistically be done?
ap
[1] http://apache.markmail.org/thread/fa6lpg7bbq32ayfl
Re: Roadmap for 1.8.0 and beyond?
Posted by Andrew Phillips <ap...@qrmedia.com>.
Related to the roadmap, but perhaps worthy of a separate discussion:
what kind of strategy are we aiming for with regard to provider
maintenance? Apart from the great work the Rackspace guys our doing,
our existing providers are generally going stale and risk becoming
outdated. vCloud and Terremark are two recent examples, but there also
hasn't been much work recently on AWS or Google stuff.
Do we need to approach users and/or vendors to ask them to contribute
time, with the chance that we will remove/deprecate all providers for
which no champion steps forward?
ap
Re: Roadmap for 1.8.0 and beyond?
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Jan 22, 2014, at 7:23 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
> But of course this can also be made to work in JIRA if there's a strong preference for that…
No strong preference. Whatever works best.
Everett
RE: Roadmap for 1.8.0 and beyond?
Posted by Andrew Phillips <ap...@qrmedia.com>.
> It's all going to wind up in JIRA anyway so why not just do it there
> to begin with?
I like the suggestion of a Wiki page because it allows for easier
collaborative changes, in my opinion. I suspect some of what's
proposed may *not* end up in JIRA for a while, so an initial round of
discussion could be useful.
But of course this can also be made to work in JIRA if there's a
strong preference for that...
ap
RE: Roadmap for 1.8.0 and beyond?
Posted by Everett Toews <ev...@RACKSPACE.COM>.
It's all going to wind up in JIRA anyway so why not just do it there to begin with?
That way we don't have to reconcile two things.
My 2 cents.
Everett
P.S. I'm in a book sprint for the next two days so I'll be unavailable. See you next week!
-----Original Message-----
From: Ignasi Barrera [ignasi.barrera@gmail.com]
Received: Wednesday, 22 Jan 2014, 5:42PM
To: {dev@jclouds.apache.org} [dev@jclouds.apache.org]
Subject: Re: Roadmap for 1.8.0 and beyond?
I'd like to have that so we can all be aligned, and users will have an
idea of what will be implemented.
This is my wish list:
* Finish the site rebranding and improve the documentation.
* Create a specialized TemplateBuilder that allows to set arbitrary
CPU and RAM. This will allow us to properly model providers that don't
use hardware profiles.
* Complete the VolumeExtension for the ComputeService.
* Give som love to the Clojure bindings; make sure they are up to date
and usable.
Shall we create a wiki page, discuss this here or use JIRA to define
the backlog?
On 22 January 2014 19:36, Andrew Phillips <ap...@qrmedia.com> wrote:
> Picking up from discussions last year about our release cadence [1]...would
> it make sense to try to put together a draft backlog for 1.8/2.0 and beyond,
> to see what development capacity we're likely to have and hence what can
> realistically be done?
>
> ap
>
> [1] http://apache.markmail.org/thread/fa6lpg7bbq32ayfl
Re: Roadmap for 1.8.0 and beyond?
Posted by Ignasi Barrera <ig...@gmail.com>.
I'd like to have that so we can all be aligned, and users will have an
idea of what will be implemented.
This is my wish list:
* Finish the site rebranding and improve the documentation.
* Create a specialized TemplateBuilder that allows to set arbitrary
CPU and RAM. This will allow us to properly model providers that don't
use hardware profiles.
* Complete the VolumeExtension for the ComputeService.
* Give som love to the Clojure bindings; make sure they are up to date
and usable.
Shall we create a wiki page, discuss this here or use JIRA to define
the backlog?
On 22 January 2014 19:36, Andrew Phillips <ap...@qrmedia.com> wrote:
> Picking up from discussions last year about our release cadence [1]...would
> it make sense to try to put together a draft backlog for 1.8/2.0 and beyond,
> to see what development capacity we're likely to have and hence what can
> realistically be done?
>
> ap
>
> [1] http://apache.markmail.org/thread/fa6lpg7bbq32ayfl
Re: Roadmap for 1.8.0 and beyond?
Posted by Andrew Gaul <ga...@apache.org>.
We should also improve the testing process for releases. I have run
blobstore tests against several providers from 1.6 onwards but including
compute providers and formalizing the process would give us more
confidence in release quality. This will require fixing broken tests.
On Thu, Jan 23, 2014 at 09:26:43AM -0800, Andrew Gaul wrote:
> In terms of pacing, releasing in March or April feels right, more
> important than any feature. We should support Java 8 and include Guava
> 16, modernizing our APIs for the latter. We should consider taking
> dependencies on Java 7 features like larger than 2 GB payloads for
> HttpURLConnection, possibly dropping Java 6 support. I would like to
> create a compatibility matrix of which features different cloud
> providers offer and jclouds support for those, e.g., checksums,
> multi-part upload, user metadata. I would also like to improve support
> for S3 work-alikes, which often implement only a subset of the API. My
> attention will likely be diverted for the next month, but I can
> contribute to all of these in the coming months.
>
> On Wed, Jan 22, 2014 at 07:36:38PM +0100, Andrew Phillips wrote:
> > Picking up from discussions last year about our release cadence [1]...would
> > it make sense to try to put together a draft backlog for 1.8/2.0 and beyond,
> > to see what development capacity we're likely to have and hence what can
> > realistically be done?
> >
> > ap
> >
> > [1] http://apache.markmail.org/thread/fa6lpg7bbq32ayfl
--
Andrew Gaul
http://gaul.org/
Re: Roadmap for 1.8.0 and beyond?
Posted by Andrew Gaul <ga...@apache.org>.
In terms of pacing, releasing in March or April feels right, more
important than any feature. We should support Java 8 and include Guava
16, modernizing our APIs for the latter. We should consider taking
dependencies on Java 7 features like larger than 2 GB payloads for
HttpURLConnection, possibly dropping Java 6 support. I would like to
create a compatibility matrix of which features different cloud
providers offer and jclouds support for those, e.g., checksums,
multi-part upload, user metadata. I would also like to improve support
for S3 work-alikes, which often implement only a subset of the API. My
attention will likely be diverted for the next month, but I can
contribute to all of these in the coming months.
On Wed, Jan 22, 2014 at 07:36:38PM +0100, Andrew Phillips wrote:
> Picking up from discussions last year about our release cadence [1]...would
> it make sense to try to put together a draft backlog for 1.8/2.0 and beyond,
> to see what development capacity we're likely to have and hence what can
> realistically be done?
>
> ap
>
> [1] http://apache.markmail.org/thread/fa6lpg7bbq32ayfl
--
Andrew Gaul
http://gaul.org/