Thanks for the posting because it tells me that there is a way to have bots contributed to infra (which I didn't know).
I have experimented with some bots, mostly against gerrit and trying to use the rather <politically-correct>lightweight</politically-correct> Launchpad API. The one bot that I still operate looks at gerrit and periodically generates an email with a list of patch sets to review. The only 'smarts' in it are that it waits a reasonable amount of time to send the email, either every 12 hours or when there are five or more patch sets to look at. I have recently been thinking that it would be a good idea to add some capabilities to help streamline handling of patches in Trove, for example around the area of translations suggested by Zanata. Also one which would update a web page based on patches to watch for a specific milestone (see other conversation on tagging and searching reviews http://openstack.markmail.org/thread/qh7u3sxmtpwkdzas) Two specific things I'd like to know are below. (a) Are there any guidelines around contributing bots, what are considered acceptable and what are not? I see mention of 'core reviewers must be human' (I was thinking my Zanata bot would +2 things, so it's a good thing to know if that's not advisable), and (b) What bots are available that we could look to using; if others have found bots that were worth contributing, it would be good to look there before reinventing the wheel. Thanks, and sorry if this is tangential to the initial intent of your email. -amrith > -----Original Message----- > From: Anita Kuno [mailto:ante...@anteaya.info] > Sent: Wednesday, March 23, 2016 4:27 PM > To: openstack-dev@lists.openstack.org >> OpenStack Development Mailing > List <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] Bots and Their Effects: Gerrit, IRC, other > > 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 > - "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
