2016/04/08 10:55、Anita Kuno <ante...@anteaya.info> : >> On 04/08/2016 01:42 PM, Dmitry Tantsur wrote: >> 2016-04-08 19:26 GMT+02:00 Davanum Srinivas <dava...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev