Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>