[openstack-dev] Bots and Their Effects: Gerrit, IRC, other

Flavio Percoco flavio at redhat.com
Thu Mar 24 16:15:57 UTC 2016


On 24/03/16 09:42 -0400, Doug Hellmann wrote:
>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.

Agreed with all the above! Those are very good arguments not to approve patches
for those cases. We had good control on these patches for Glance during Mitaka.
They were normally approved really quick unless there were outages.

That said, I'm still not against the concept of having a bot +2A a patch for
very specific cases. I guess I just don't have a good example at hand now.

Flavio

>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
>>
>
>__________________________________________________________________________
>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160324/df2656ba/attachment.pgp>


More information about the OpenStack-dev mailing list