[openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

Ken'ichi Ohmichi ken1ohmichi at gmail.com
Sat Apr 9 19:04:44 UTC 2016


2016/04/08 10:55、Anita Kuno <anteaya at anteaya.info> :

>> On 04/08/2016 01:42 PM, Dmitry Tantsur wrote:
>> 2016-04-08 19:26 GMT+02:00 Davanum Srinivas <davanum at gmail.com>:
>> 
>>> Team,
>>> 
>>> Steve pointed out to a problem in Stackalytics:
>>> https://twitter.com/stevebot/status/718185667709267969
>> 
>> 
>> There are many ways to game a simple +1 counter, such as +1'ing changes
>> that already have at least 1x +2, or which already approved, or which need
>> rechecking...

Can we merge this kind of patches without reviews?
When seeing this kind of patches, I check all jobs are succeeded. Sometimes some job failed, I check the reason and +2 if that is unrelated.

This workflow seems possible to be implemented automatically.
Or bad idea?

Thanks








>> 
>> 
>>> 
>>> 
>>> It's pretty clear what's happening if you look here:
>>> 
>>> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
>>> 
>>> Here's the drastic step (i'd like to avoid):
>>> https://review.openstack.org/#/c/303545/
>>> 
>>> What do you think?
>> 
>> One more possible (though also imperfect) mitigation is to make exception
>> from the usual 2x +2 rule for requirements updates passing gates and use
>> only 1x +2. Then requirements reviews will take substantially less time to
>> land, reducing need/possibility of having such +1's.
> 
> Proposal bot patches merge in many cases with 1 +2 already.
> 
> Have you looked at the timing of the bot patches generated and the first
> +1's? If not, take a look at that.
> 
> I don't think we should be expecting core reviewers to schedule
> approving bot proposals to prevent extraneous +1s.
> 
> Thanks,
> Anita.
> 
>> 
>>> 
>>> Thanks,
>>> Dims
>>> 
>>> --
>>> Davanum Srinivas :: https://twitter.com/dims
>>> 
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list