On Jul 30, 2014, at 6:22 PM, Andrew Gaul <g...@apache.org> wrote: > What if we continue to use the labs repository as a staging area but > stop releasing it?
I think this could be a viable approach but I have some questions below. > This will allow development of new providers to > proceed and user testing via snapshots but not impact the release > process. Obviously, this will require migrating the mature providers to > core, which we seem to agree should happen anyway. Agreed. I’m assuming this includes apis/providers that aren’t associated with an abstraction, since that seems to be our de facto position anyway. Was that your intention as well? There’s one scenario that I would like to know is okay with everybody before going down this path because “mature” is not well defined. When it comes to a trusted committer adding an api/provider, we would need to be able to move it into the main repo as soon as it has a minimal amount of features that make the api useful (this will vary from api to api). By trusted committer, I mean those who are known to deliver quality apis and maintain them. The work could start in a labs repository or maybe even the master branch of the main repo, if we’re not too close to a major point release. As soon as we’ve reached a minimal amount of useful features, we move it to the main repo or back port it into a release branch (if it started in the master branch of the main repo). I ask about this because we need to be able to provide value to our users quickly in actual releases. The users we work with don’t care to take snapshot releases and many will outright refuse snapshot releases. These are the same users who appreciate the predictability of things like semver. Right now we can help these users because the labs repos are being released. If we are not releasing the labs repos, it is extremely important to me that we be able to move code into the main repo as soon as it has a minimal amount of useful features and has met the jclouds quality standard (i.e. has been reviewed throughly in our PR process and has live and mock tests). What is everyone’s thoughts on that? >> 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. > > Honestly I do not understand karaf and see it as something outside of > the main jclouds project. As for cli, we should replace it with > something friendlier and lightweight such as: Are we reaching a consensus on removing karaf and cli from our release process? Am I reading this right? Seems we’re all agreed they're more downstream users of jclouds than part of jclouds itself. Does that mean not releasing them along with jclouds? It would be really great to hear from somebody with a vested interest in karaf and cli on this. Thanks, Everett
