On Dec 2, 2014, at 2:31 PM, Ignasi Barrera <n...@apache.org> wrote: > This said, the absence of an abstraction (take network or databases as > an example) shouldn't be a blocker. Abstractions can be proposed in > the mailing list, and even better discussed in a PR! We are all > looking to improve jclouds to make it better for the users, and that > means making it more portable. Let's work on adding an abstraction > when that makes sense! But things have to be *real* and that work has > to be done. Without it, it does not make sense to promote/keep such > apis/providers.
I think having everything in jclouds/jclouds could possibly work but we would need to be more specific about the above. Otherwise I’m concerned we’d wind up in the same place 6 months down the road. If this were to be the path we go down, I have some clarifying questions. These are open questions for anyone to answer. “the absence of an abstraction shouldn’t be a blocker” 1. So once an api meets the criteria of having a steward, being modern, and having a proper test suite, it can immediately be promoted? “Let's work on adding an abstraction when that makes sense!” 2. Can you elaborate on this point? Did you have some criteria in mind for what “makes sense” means? "it does not make sense to promote/keep such apis/providers.” These are two different concerns and should be broken out. "it does not make sense to promote such apis/providers.” 3. Are you saying that if there’s an api that would never be a good fit for abstraction, that it has no chance of being promoted? "it does not make sense to keep such apis/providers.” 4. Are you saying that if an abstraction doesn’t happen in some amount of time, that any apis related to that lack-of-abstraction would be removed? Everett
