jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Phillips <aphill...@qrmedia.com>
Subject RE: [DISCUSS] What is the criteria for something to be in the jclouds/jclouds repo?
Date Fri, 12 Dec 2014 22:42:58 GMT
To echo what Ignasi said, I think we need to note that jclouds calls  
itself "the Java multi-cloud toolkit." To find out what that means in  
the face of some pretty big changes in cloud usage, I think we really  
need to ask our users, but more on that in a different thread. To me,  
the "multi-cloud" in that definition means a couple of things:

1. Providing useful, portable cloud abstractions that are relevant to  
our users now and going forward
2. In APIs and providers, focusing on code that allows us to implement  
those abstractions
3. Ensuring that APIs and providers, especially the most popular ones,  
remain up-to-date and functional
4. Allowing jclouds to be used in as many JVM-based environments, with as few
implications for your code, as feasible

By extension, this also means:

5. Pulling in as few dependencies as possible, and in general imposing minimum
constraints on user code
6. Spending less time trying to support non-portable features in APIs  
and providers (whilst being open to updating the portable  
abstractions, or adding new ones, where justified!)
7. Spending less time supporting APIs and providers that are unrelated  
to portable abstractions
8. Prioritizing issues or missing features in providers that are most  
heavily used, rather than those you happen to be familiar with
9. Removing APIs and providers that no longer work

Taking into account the reality of limited resources, my suggestion  
(concretely, for 1.9.0) would be to try to make jclouds as lean, mean  
and easy to contribute to as possible:

* promote all providers and APIs that implement abstractions and are  
in common use to jclouds/jclouds
* complete half-finished abstractions and discuss where existing  
abstractions need to be modernized
* remove all deadwood providers and APIs
* create an "example PR" of how to add a new minimal provider or API,  
using the "latest and greatest" jclouds dev practices (@nacx: would  
the Abiquo re-impl be a good candidate?)

Regards

ap

Mime
View raw message