[openstack-dev] [nova] bug triage experimentation

Sean Dague sean at dague.net
Mon Jul 10 11:24:14 UTC 2017

On 07/05/2017 03:07 PM, Emilien Macchi wrote:
> On Wed, Jun 28, 2017 at 7:33 AM, Ben Nemec <openstack at nemebean.com> wrote:
>> On 06/23/2017 11:52 AM, Sean Dague wrote:
>>> The Nova bug backlog is just over 800 open bugs, which while
>>> historically not terrible, remains too large to be collectively usable
>>> to figure out where things stand. We've had a few recent issues where we
>>> just happened to discover upgrade bugs filed 4 months ago that needed
>>> fixes and backports.
>>> Historically we've tried to just solve the bug backlog with volunteers.
>>> We've had many a brave person dive into here, and burn out after 4 - 6
>>> months. And we're currently without a bug lead. Having done a big giant
>>> purge in the past
>>> (http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html)
>>> I know how daunting this all can be.
>>> I don't think that people can currently solve the bug triage problem at
>>> the current workload that it creates. We've got to reduce the smart
>>> human part of that workload.
>>> But, I think that we can also learn some lessons from what active github
>>> projects do.
>>> #1 Bot away bad states
>>> There are known bad states of bugs - In Progress with no open patch,
>>> Assigned but not In Progress. We can just bot these away with scripts.
>>> Even better would be to react immediately on bugs like those, that helps
>>> to train folks how to use our workflow. I've got some starter scripts
>>> for this up at - https://github.com/sdague/nova-bug-tools
>> Just saw the update on https://bugs.launchpad.net/nova/+bug/1698010 and I
>> don't agree that assigned but not in progress is an invalid state.  If it
>> persists for a period of time then sure, but to me assigning yourself a bug
>> is a signal that you're working on it and nobody else needs to. Otherwise
>> you end up with multiple people working a bug without realizing someone else
>> already was.  I've seen that happen more than once.
>> Would it be possible to only un-assign such bugs if they've been in that
>> state for a week?  At that point it seems safe to say the assignee has
>> either moved on or that the bug is tricky and additional input would be
>> useful anyway.
>> Otherwise, big +1 to a bug bot.  I need to try running it against the ~700
>> open TripleO bugs...
> I just tried, please send complains to me if I broke something.
> Sean, the tool is really awesome and I was wondering if we could move
> it to https://github.com/openstack-infra/release-tools so we
> centralize the tools.

Probably yes, eventually? Right now I'm honestly trying to figure out
the things that are useful here, and the ones that aren't, so a more
fluid experimentation is worth while.

My end game is to get some of these running and responding in real time
which means the core processing logic is going to evolve away from
scripts and into some kind of function plugin (the batch interface will
just still call them).


Sean Dague

More information about the OpenStack-dev mailing list