Re: Labs repos rejoining the main repo

[Everett Toews <ev...@RACKSPACE.COM>]

On Jul 30, 2014, at 6:22 PM, Andrew Gaul <ga...@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

Re: Labs repos rejoining the main repo

[Everett Toews <ev...@RACKSPACE.COM>]

On Aug 1, 2014, at 9:55 AM, Andrew Phillips <ap...@qrmedia.com> wrote:

>> 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.
> 
> This is really a different discussion that I'd like to pursue elsewhere, but who are "the users we work with" here? Do we have any details that we can share?

Sigh…no.

> It's certainly not that I want to cast any doubt on the above statement. I just feel that getting a better idea of our *actual* user population and the different requirements within it would really help in terms of determining priorities and direction.

I can only sum it up as these things are important to a portion of our user base. Many of our enterprise customers are not willing to publicly share what tools they use in their applications. This is the default position of many (most?) enterprise shops. In the near future I’m going to be making a concerted effort to change minds on this but it’s an uphill climb.

Apologies for the distracting comment. Let’s focus on the labs repos here.

Everett

Re: Labs repos rejoining the main repo

[Andrew Phillips <ap...@qrmedia.com>]

> 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.

This is really a different discussion that I'd like to pursue  
elsewhere, but who are "the users we work with" here? Do we have any  
details that we can share?

It's certainly not that I want to cast any doubt on the above  
statement. I just feel that getting a better idea of our *actual* user  
population and the different requirements within it would really help  
in terms of determining priorities and direction.

I think it would be great to get more numbers like the ones Andrew G  
extracted from JIRA about which versions of Java our users seem to be  
using when the Java 6/7 discussion was going on.

Thoughts on how to go about this, assuming we feel it's possible?  
Worth bringin up the survey idea [1] again here?

ap

[1] http://markmail.org/message/or7xmsqry6qqwfpx