On Apr 9, 2016 12:05, "Ken'ichi Ohmichi" <ken1ohmi...@gmail.com> wrote: > > > 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 >
A true automerge has potential to accidentally clobber things in an ugly way if it goes wrong. The auto propose but core approval still has a level of human spot checking. I would personally be uncomfortable with the bot automatically merging things. At face value the overhead of a core approval and possibility of what is highlighted in this thread is better IMHO. > > > > > > > > >> > >> > >>> > >>> > >>> 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
__________________________________________________________________________ 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
