Open Stack

> -----Original Message-----
> From: Flavio Percoco [mailto:flavio at redhat.com]
> Sent: Thursday, March 24, 2016 9:13 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Bots and Their Effects: Gerrit, IRC, other
> 
> 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.
> 

[amrith] I'm strongly against that in Trove (and I can see similar issues for other project that have guest images with python packages installed). I know that +2A for requirement patches wasn't the thrust of this email thread, but I just want to point out that in cases like Trove where there are guest images with requirements of their own, the patches with requirement changes have very material and consequential impacts and often get -2'ed while we can resolve dependent issues. And when some things like this have slipped through the cracks, very very bad things have happened.

> 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.ht
> >ml
> >[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-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> --
> @flaper87
> Flavio Percoco