Excerpts from Flavio Percoco's message of 2016-03-24 09:12:36 -0400: > On 23/03/16 16:27 -0400, Anita Kuno wrote: > >Bots are very handy for doing repetitive tasks, we agree on that. > > > >Bots also require permissions to execute certain actions, require > >maintenance to ensure they operate as expected and do create output > >which is music to some and noise to others. Said output is often > >archieved somewhere which requires additional decisions. > > > >This thread is intended to initiate a conversation about bots. So far we > >have seen developers want to use bots in Gerrit[0] and in IRC[1]. The > >conversation starts there but isn't limited to these tools if folks have > >usecases for other bots. > > > >I included an item on the infra meeting agenda for yesterday's meeting > >(April 22, 2016) and discovered there was enough interest[2] in a > >discussion to take it to the list, so here it is. > > > >So some items that have been raised thus far: > >- permissions: having a bot on gerrit with +2 +A is something we would > >like to avoid > > To be honest, I wouldn't mind having a bot +2A on specific cases. An example > would be requirements syncs that have passed the gate or trasnlations. I > normally ninja-approve those and I don't really mind doing it but, I wouldn't > mind having those patches approved automatically since they don't really > require > a review.
The problem with automating some of those things is we have to take into account schedules, outages, gate issues, and other reasons when we should *not* take automated actions. We can code some of those things into the bots, but I expect there will always be special cases. To look at patches generated by bots (Zanata, requirements updates, etc.), we purposefully have those bots introduce the patches because producing them is a repetitive task, ripe for automation. We do not let the bots automatically approve those patches so we can retain control over *when* changes land, because knowing when it's OK to merge a change requires knowledge outside of what the bot will have. This is also why we've been working so hard to put together a reviewable release process. Building the package is highly automatable. Knowing when it's OK to build the package is not. Doug > > Flavio > > >- "unsanctioned" bots (bots not in infra config files) in channels > >shared by multiple teams (meeting channels, the -dev channel) > >- forming a dependence on bots and expecting infra to maintain them ex > >post facto (example: bot soren maintained until soren didn't) > >- causing irritation for others due to the presence of an echoing bot > >which eventually infra will be asked or expected to mediate > >- duplication of features, both meetbot and purplebot log channels and > >host the archives in different locations > >- canonical bot doesn't get maintained > > > >It is possible that the bots that infra currently maintains have > >features of which folks are unaware, so if someone was willing to spend > >some time communicating those features to folks who like bots we might > >be able to satisfy their needs with what infra currently operates. > > > >Please include your own thoughts on this topic, hopefully after some > >discussion we can aggregate on some policy/steps forward. > > > >Thank you, > >Anita. > > > > > >[0] > >http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-03-09.log.html#t2016-03-09T15:21:01 > >[1] > >http://lists.openstack.org/pipermail/openstack-dev/2016-March/089509.html > >[2] > >http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-22-19.02.log.html > >timestamp 19:53 > > > >__________________________________________________________________________ > >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