I have a quick question: How is anyone hurt out harmed by the practice? I agree it isn't helpful. But it isn't harming either. It could be gaming and it could be ignorance - mistakes by not knowing.
I'm asking because I see the same predictable personalities making passive aggressive accusations against their peers about gaming and ill intent. When folks are approached, they realize it is due to not knowing. Their answers are received with suspicion and presumptions that they are in the minority. We really need to stop rushing to embrace the worst in each other. //adam On Apr 9, 2016 1:18 PM, "Morgan Fainberg" <morgan.fainb...@gmail.com> wrote: 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
__________________________________________________________________________ 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
