smashing repos

[Adrian Cole]

Hi, team.

It should be relatively unsurprising that the move to ASF incubation will result in code transitions :)  On irc today, I had a discussion I'll call "pain tolerance" which could be roughly summarized as "few folks are willing to work on providers they don't use, and even fewer for providers no-one uses".  The jist is that now that jclouds requires no central registration of providers, unpopular or incomplete provider code need not weigh down our committers work load, and certainly needn't distract us when we transition into ASF.  We can't rely on my high tolerance for pain to be the implicit champion for unpopular, abandoned, or unfinished code.  This is not the apache way, nor is it fair.   This doesn't mean I won't volunteer to champion a ton of stuff, just don't expect me to be the fallback for all code nobody else wants or wants to touch.  Code in that category should be scrapped vs dumped into apache.

We will have this discussion again inside ASF incubation (which should start shortly).  However, we need to consider some logistics now, so here's a stab:

In summary, if there is no champion for a driver, api, or provider, it shouldn't be moved into ASF incubation. 

If we agree, we know that during the incubation we will need to cherry-pick wisely from existing repos based on what holds highest benefit, and has a clear and explicit champion (or champions).  This probably goes beyond "cloud portability turing complete" but less than all providers that have ever been started in jclouds.  Each of the modules moved in should have at least one committer vouching for it, which means they are prepared to help maintain or review code for it.  For example, I'm inclined to vouch for a project I don't work on, provided there's clear history of community support (and not burdensome wrt pull reviews) (ex. fgcp).  Folks can make their own decisions on how they feel vouching makes sense to them.

If the above is correct, it will likely help making responsibilities explicit vs implicit.  For example, we should split out of jclouds-labs anything no-one is working on.  If these repos fail to find a champion, or even someone to fork it before jclouds completes incubation, they can just die.  

There's no plan to release jclouds 1.7, as the next release is ASF, and likely renamed to Apache jclouds 2.0 to fix our semantic versioning issues.  There's no reason to migrate any module into incubation unless it is current and supportable.  Hence, after 1.6 is final, we should split all repos up, even "core".  There are modules no-one maintains, nor has asked any question about in a year.  There are also modules which are behind on versions (ex. cloudsigma, apachehc, terremark, cloud): these need to be rewritten or updated before they become dead weight.  Folks need to consider these "at risk" and step up, don't assume I will as I have no ambition to dump junk into apache.

Anyhow, this should be enough of a conversation primer.  With jclouds 1.6.0 and our incubation proposal coming soon, we need to think hard about how to bring value and transition.

-A

[Everett Toews]

For the record, Rackspace (Everett Toews and Zack Shoylev) will champion the OpenStack and Rackspace APIs/Providers.

Cheers!

Everett

--
You received this message because you are subscribed to the Google Groups "jclouds-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jclouds-dev...@googlegroups.com.
To post to this group, send email to jclou...@googlegroups.com.
Visit this group at http://groups.google.com/group/jclouds-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Adrian Cole]

Here are some steps in labs that will help get the high-value components out sooner rather than later.  

I'll vouch to help at least review the following:

https://github.com/jclouds/jclouds-labs/issues/35 - jclouds-labs-openstack (plus rax and possibly hp when relevant)

https://github.com/jclouds/jclouds-labs/issues/36 - jclouds-labs-google (oauth + gce)

https://github.com/jclouds/jclouds-labs/issues/37 - jclouds-labs-aws (elb, iam, rds)

Feel free to open issues for others folks want to step-up on.

-A

[Jeremy Daggett]

I will definitely assist on the OpenStack APIs. ;)

/jd

[Matt Stephenson]

For OpenStack, I think it's important that the champions are also individual members of the foundation, and not merely representatives of a corporate member.

Matt 

[Adrian Cole]

Agreed.  If this is not the case for anyone interested, please fill this thing out as it only makes sense.

https://www.openstack.org/join/register/

-A

[Everett Toews]

Agreed. 

Personally, I've been active in the OpenStack community and foundation member since before I started working for Rackspace. To join anyone can go to,

https://www.openstack.org/join/

Cheers,

Everett

[Andrew Phillips]

> I'll vouch to help at least review the following:

Will also try to pitch in with reviews if I can help with anything.

ap

[Roman Shaposhnik]

On Fri, Apr 5, 2013 at 3:38 PM, Adrian Cole <adrian...@gmail.com> wrote:

> Hi, team.
>
> It should be relatively unsurprising that the move to ASF incubation will
> result in code transitions :) On irc today, I had a discussion I'll call
> "pain tolerance" which could be roughly summarized as "few folks are willing
> to work on providers they don't use, and even fewer for providers no-one
> uses". The jist is that now that jclouds requires no central registration
> of providers, unpopular or incomplete provider code need not weigh down our
> committers work load, and certainly needn't distract us when we transition
> into ASF. We can't rely on my high tolerance for pain to be the implicit
> champion for unpopular, abandoned, or unfinished code. This is not the
> apache way, nor is it fair. This doesn't mean I won't volunteer to
> champion a ton of stuff, just don't expect me to be the fallback for all
> code nobody else wants or wants to touch. Code in that category should be
> scrapped vs dumped into apache.

This will jive very well with ASF's 'community over code motto'. Kudos to you
guys for proactively tackling the challenge

Thanks,
Roman.

[Adrian Cole]

ps had a good chat with henning on irc about responsibility and modularity.

Going idea is to setup a main jclouds repo in apache's git namespace and also ones per provider, api, driver.  The latter repos would be "lazy-created" by folks who care enough to set it up and have support by one or more committers.

I'll do my best to save further discussion for the incubator mailing lists.. to that end, please help Becca however you can wrt proposal submission!

https://groups.google.com/forum/?fromgroups=#!topic/jclouds-dev/mjRiig6Msqs

-A

[Adrian Cole]

OK please note I've cut fresh new repositories for staging "vouched" labs apis for migration into similarly named repositories once we enter apache incubation

ex. jclouds-labs-aws -> incubator-jclouds-labs-aws

https://github.com/jclouds/jclouds-labs-aws

https://github.com/jclouds/jclouds-labs-openstack

https://github.com/jclouds/jclouds-labs-google

https://github.com/jclouds/jclouds/issues/1576

HTH

-A

On Fri, Apr 5, 2013 at 3:38 PM, Adrian Cole <adrian...@gmail.com> wrote: