Here I am with Andrew P. and believe that karat and CLI are more downstream "clients" of jclouds than actual parts of the project.
I would keep them in their own repositories. Furthermore, the karat tests take about 17 min. to complete and often present indeterministic failures that are difficult to diagnose/reproduce. We don't have that expertise on Karaf (hopefully this is something we can fix soon), and having it in the main repo IMHO would cause now more trouble than benefits. Regarding the labs repos, there is a mix: * There are providers that work quite well: gee, digitalocean, cloudsigma2, the rackspace ones. * There are providers that are obsolete (work with old versions of the apis) but are being used by some users: abiquo (is being used by NEC). * There are providers that are directly broken and are unusable: joyentcloud * There are providers that are more like "experiments" that never got the maturity level to be merged to the main repo. Given this scenario, I think we should take a different approach depending on the providers: * I'm OK to merge to the main repo the stable ones, and the ones that are obsolete but used, as we know they're working as expected. We want to keep releasing them, and can expect bug fixes and contributions. * Keep all the broken and experimental providers in the labs repo, and poll in the user/dev mewling lists, and other channels such as twitter, etc, to see if there are real users of those providers. Then decide if we drop them or not. * Those providers that the community is using but are in labs could be moved to the main repo. This is the "conceptual approach". Talking about the implementation, I'd suggest: * Move the providers to the main repo, but keep them in a "labs" folder, just as we did in early jclouds versions. We still want to keep the semantics that they're not mature or are in beta stages. Moving them out to the apis/providers folders is trivial and should keep the git history, so that shouldn't be a problem. It will also make it easier to include/exclude the labs projects from the releases, or the creation of a "labs" maven profile that gives us more flexibility on what has to be built. Finally, regarding the "level of maturity" question, I don't think we should accept contributions that are not mature enough to join directly the main repo as a top level provider. We should gather live test output feedback for every new provider and work with the contributors to reach the desired quality. It makes no sense to merge a contribution that does not meet our quality standards just because "it goes to the labs repo and eventually the provider will get improved". Experience shows that this won't happen. I. On 29 July 2014 05:06, Everett Toews <everett.to...@rackspace.com> wrote: > On Jul 28, 2014, at 9:16 PM, Andrew Phillips <aphill...@qrmedia.com> wrote: > >> As regards karaf and cli: would they belong in core, or in tools or >> elsewhere? They're really more downstream consumers of jclouds than *parts* >> of jclouds themselves. > > Originally I thought of the tools dir as just being a collection of scripts > but it could be more than that. If we did put karaf and cli and the BlobStore > stuff in there it’s clear that it would become something of a catch-all for > jclouds related stuff that we want to keep close. I’m not necessarily against > that but we need to be clear about the intention of the tools dir. > > Personally, I’ve never used karaf or the cli so I don’t feel strongly about > where they go or even if they stay within our repo. I hope the maintainers of > these things speak up here. > > Everett >
