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 supp...@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 <adrian.f.c...@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 > <everett.to...@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 <g...@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/ >>
