jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Turli <andrea.tu...@gmail.com>
Subject RE: [DISCUSS] What is the criteria for something to be in the jclouds/jclouds repo?
Date Tue, 02 Dec 2014 17:44:47 GMT
Hi,

I personally think we should consider a couple of additional criteria to
the good Zack's list.
The code should support the latest stable (recommended) version of the API.
The implementation should follow all the current guidelines (i. e. Use of
Auto Value and Service, MWS, no async API)  so that the new providers don't
introduce tech debt, this should be kept during reviews but we need some
standard way to "enforce" them.
MockTests and LiveTests have to be green.
The maintainer has to be able to run the LiveTests for each release.

As contributor to labs repos this is my understanding of what it is needed
to get the provider out of labs, hope this helps.

Andrea
Il 02/dic/2014 18:28 "Zack Shoylev" <zack.shoylev@rackspace.com> ha scritto:

> Possible criteria that have been discussed before:
>
> 1. If it is out of beta
> 2. If it has a maintainer
> 3. If it has a jclouds abstraction layer
> 4. Voted on a case by case basis (current way of doing things)
>
> Are there any more possible criteria I have left out? In the end it will
> be some mix of the above. My thoughts on this is that 2) is sufficient.
> -Zack
> ________________________________________
> From: Dancy, Chris [Chris.Dancy@pega.com]
> Sent: Tuesday, December 02, 2014 8:27 AM
> To: dev@jclouds.apache.org
> Subject: Re: [DISCUSS] What is the criteria for something to be in the
> jclouds/jclouds repo?
>
> As an occasional contributor, and currently coding a Shipyard provider
> (JCLOUDS-782), I do have a vested interest in how this ends up. IMO I
> think having a clear separation of ³core² projects vs ³baking² projects is
> a good idea but it seems that is not working out so great here? Are there
> other proposals on how to do this?
>
> On 12/2/14, 4:09 AM, "Inbar Stolberg" <inbarsto@gmail.com> wrote:
>
> >I think openstack neutron should be in jcluods master currently it suffers
> >from being left out even though it is being updated and runs on openstack
> >api v2.
> >
> >regarding glance I think after
> >https://github.com/jclouds/jclouds-labs-openstack/pull/77 is merged we
> >should move it.
> >
> >regarding Ceilometer I think that taking to accout what you said Everett:
> >" in email threads or IRC chats most everybody agrees that the labs repos
> >are a failed experiment"
> >maybe its worth considering porting it to jclouds/jclouds from right after
> >the merge of :
> >https://github.com/jclouds/jclouds-labs-openstack/pull/166
> >
> >(which btw I am already going to use in production code...)
> >
> >my 2 cents
> >Regards Inbar
> >
> >
> >On Tue, Dec 2, 2014 at 2:06 AM, Everett Toews
> ><everett.toews@rackspace.com>
> >wrote:
> >
> >> What is the criteria for something to be in the jclouds/jclouds repo
> >>[1]?
> >>
> >> Before we go moving any more code around or removing any more
> >> apis/providers we need to step back and have some agreed upon criteria
> >>for
> >> what belongs in jclouds/jclouds and what doesn¹t. If we don¹t do that
> >>our
> >> decisions are effectively arbitrary and the questions of ³What to do
> >>about
> >> X?² will continue to come up.
> >>
> >> I took a shot at addressing a topic like this in "Criteria for moving an
> >> api/provider from a labs repo to core² [2] but I got zero replies.
> >>People
> >> seem to be unwilling or uninterested in tackling this question and I
> >>think
> >> jclouds is suffering because of it. It¹s puzzling to me because in email
> >> threads or IRC chats most everybody agrees that the labs repos are a
> >>failed
> >> experiment. So let¹s flip it around and discuss what belongs in
> >> jclouds/jclouds instead.
> >>
> >> I know for a fact that many contributors have an opinion on this. Let¹s
> >> hear it!
> >>
> >> Thanks,
> >> Everett
> >>
> >> [1] https://github.com/jclouds/jclouds
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message