Open Stack

On 11/18/2014 03:44 PM, Clark Boylan wrote:
> On Mon, Nov 17, 2014, at 04:21 PM, Jeremy Stanley wrote:
>> When we put together our third-party CI account naming scheme a few
>> months ago, discussion was mostly focused on how to avoid confusion
>> on official projects where we have upwards of 50 systems providing
>> feedback on a proposed change. Requirements like "include the name
>> of your company and subsystem being tested" or "the account name
>> can't include the name of the project" make sense there, but we have
>> another somewhat unrelated use case for these accounts which also
>> needs some consideration.
>>
>> Consider a project whose community collaboratively maintains a
>> single external test system to provide feedback about things that we
>> won't or can't easily test in our infrastructure... I've seen a lot
>> of confusion around how those accounts are allowed to be named.
>> Consider the following existing accounts as examples:
>>
>>     Compass CI
>>     Docker CI
>>     Fuel CI
>>     MagnetoDB CI
>>     Puppet CI
>>     Sahara Hadoop Cluster CI
>>
>> I've proposed https://review.openstack.org/135050 in an attempt to
>> reach some consensus that for this particular use case, having an
>> account like "YourProject CI" for your community to use in reporting
>> test results on your project is acceptable. I'm bringing this up now
>> because we have somewhere around half a dozen outstanding account
>> requests (some more than a month old) matching this particular
>> pattern and I'd like to be able to just go ahead and take care of
>> them, but I don't want to go upsetting anyone over the possibility
>> that we've violated our hard-and-fast rules for third-party CI
>> account naming.
>> -- 
>> Jeremy Stanley
>>
>> _______________________________________________
>> OpenStack-Infra mailing list
>> OpenStack-Infra at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 
> +2 (and I have voted that way on 135050). Stackforge exists to encourage
> awesomeness and when the frameworks it is built on impede that we should
> consider updating the framework. There is clearly a need for third party
> testing for Stackforge projects and they may not have a company backing
> or subsystem being tested. They just need to run tests outside of
> upstream for reasons and we should enable that.

I have never agreed more strongly with Clark.