module stewards

[Andrew Gaul <ga...@apache.org>]

Following on to the steward discussion[1], I created a wiki of all the
jclouds modules on our wiki:

https://wiki.apache.org/jclouds/Stewards

I would like to assign stewards for all modules; please add yourself to
the ones which interest you.  This process may identify some orphan
providers and hopefully we can source a steward from the community or
vendor.  Otherwise we may schedule that module for removal.

[1] http://mail-archives.apache.org/mod_mbox/jclouds-dev/201410.mbox/browser

-- 
Andrew Gaul
http://gaul.org/

Re: module stewards

[Adrian Cole <ad...@gmail.com>]

PS for folks not on irc, one potential gain we can do is to make
transparent who is owning testing the cloud and supporting the api.
This covers use cases needed when we used to run live tests on each
major release
http://jclouds.apache.org/releasenotes/1.5-tests/

For example, tester field could hold Cludowa corp, who offer to run
live tests on providers a, b, c but can't offer help coding.

It also covers support@foobar.com, who can reset our account password,
explain or expedite api drift errors, but also can't currently help
code.

Support could also be Max, who helped integrate jclouds driver foo, by
solving problems on the foo side.

I agree that having 3 columns of data (steward, tester, support) on
each module may seem heavy, but the above scenarios are real and
repeatable.

Back in the day, I knew all of these, and that's how I could do live
tests in one weekend by myself. If we make this data visible, we give
each module best chance of success.  It also gives us 3 signals to
show something is dead and should be removed. For example, lack of
support ended in our removal of eucalyptus pre-ASF.

-A



On Mon, Oct 6, 2014 at 5:24 PM, Adrian Cole <ad...@gmail.com> wrote:
> Makes sense for providers especially, but also for api groups where
> there's a clear owner for all. For example, we aren't with the same
> luxury on aws or azure yet.
>
> On Mon, Oct 6, 2014 at 1:57 PM, Everett Toews
> <ev...@rackspace.com> wrote:
>> Any objections to using wildcards for brevity’s sake where it makes sense?
>>
>> e.g.
>>
>> openstack-*
>> elastichosts-*
>> rackspace-*
>> hpcloud-*
>> cloudsigma2-*
>>
>> Probably doesn’t make sense for aws providers/apis as stewardship of them isn’t uniform.
>>
>> Everett
>>
>>
>> On Oct 6, 2014, at 2:03 PM, Andrew Gaul <ga...@apache.org> wrote:
>>
>>> Following on to the steward discussion[1], I created a wiki of all the
>>> jclouds modules on our wiki:
>>>
>>> https://wiki.apache.org/jclouds/Stewards
>>>
>>> I would like to assign stewards for all modules; please add yourself to
>>> the ones which interest you.  This process may identify some orphan
>>> providers and hopefully we can source a steward from the community or
>>> vendor.  Otherwise we may schedule that module for removal.
>>>
>>> [1] http://mail-archives.apache.org/mod_mbox/jclouds-dev/201410.mbox/browser
>>>
>>> --
>>> Andrew Gaul
>>> http://gaul.org/
>>

Re: module stewards

[Adrian Cole <ad...@gmail.com>]

Makes sense for providers especially, but also for api groups where
there's a clear owner for all. For example, we aren't with the same
luxury on aws or azure yet.

On Mon, Oct 6, 2014 at 1:57 PM, Everett Toews
<ev...@rackspace.com> wrote:
> Any objections to using wildcards for brevity’s sake where it makes sense?
>
> e.g.
>
> openstack-*
> elastichosts-*
> rackspace-*
> hpcloud-*
> cloudsigma2-*
>
> Probably doesn’t make sense for aws providers/apis as stewardship of them isn’t uniform.
>
> Everett
>
>
> On Oct 6, 2014, at 2:03 PM, Andrew Gaul <ga...@apache.org> wrote:
>
>> Following on to the steward discussion[1], I created a wiki of all the
>> jclouds modules on our wiki:
>>
>> https://wiki.apache.org/jclouds/Stewards
>>
>> I would like to assign stewards for all modules; please add yourself to
>> the ones which interest you.  This process may identify some orphan
>> providers and hopefully we can source a steward from the community or
>> vendor.  Otherwise we may schedule that module for removal.
>>
>> [1] http://mail-archives.apache.org/mod_mbox/jclouds-dev/201410.mbox/browser
>>
>> --
>> Andrew Gaul
>> http://gaul.org/
>

Re: module stewards

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

Any objections to using wildcards for brevity’s sake where it makes sense?

e.g.

openstack-*
elastichosts-*
rackspace-*
hpcloud-*
cloudsigma2-*

Probably doesn’t make sense for aws providers/apis as stewardship of them isn’t uniform.

Everett


On Oct 6, 2014, at 2:03 PM, Andrew Gaul <ga...@apache.org> wrote:

> Following on to the steward discussion[1], I created a wiki of all the
> jclouds modules on our wiki:
> 
> https://wiki.apache.org/jclouds/Stewards
> 
> I would like to assign stewards for all modules; please add yourself to
> the ones which interest you.  This process may identify some orphan
> providers and hopefully we can source a steward from the community or
> vendor.  Otherwise we may schedule that module for removal.
> 
> [1] http://mail-archives.apache.org/mod_mbox/jclouds-dev/201410.mbox/browser
> 
> -- 
> Andrew Gaul
> http://gaul.org/