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" <inbar...@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.to...@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
