[openstack-dev] [nova] bug triage experimentation

Markus Zoeller mzoeller at linux.vnet.ibm.com
Thu Jun 29 07:04:24 UTC 2017

On 28.06.2017 16:50, Sean Dague wrote:
> On 06/28/2017 10:33 AM, Ben Nemec 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.
> The other case, where folks assign themselves and never do anything,
> happens about 100 times a month.
> We don't live in an exclusive lock environment, anyone can push a fix
> for a bug, and gerrit assigns it to them. I don't see why we'd treat LP
> any differently. Yes, this sometimes leads to duplicate fixes, however
> in the current model it's far more frequent for bugs to be blocked away
> as "assigned" when no one is working on them.
> A future version might be smarter and give folks a 7 day window or
> something, but parsing back the history to understand the right logic
> there is tricky enough that it's a future enhancement at best.
> 	-Sean

+1 That happened so frequently I made a query for that:

After poking people to get the actual state, 99% of the time the answer
was "I couldn't work on it, please remove my assignment.".

Regards, Markus Zoeller (markus_z)

More information about the OpenStack-dev mailing list