[openstack-dev] [nova] bug triage experimentation

Sean Dague sean at dague.net
Mon Jun 26 11:11:26 UTC 2017

On 06/26/2017 04:49 AM, Sylvain Bauza wrote:
> Le 23/06/2017 18:52, Sean Dague a écrit :
>> 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.
> Thanks for sharing ideas, Sean.
>> 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
> Sometimes, I had no idea why but I noticed the Gerrit hook not working
> (ie. amending the Launchpad bug with the Gerrit URL) so some of the bugs
> I was looking for were actively being worked on (and I had the same
> experience myself although my commit msg was pretty correctly marked AFAIR).
> Either way, what you propose sounds reasonable to me. If you care about
> fixing a bug by putting yourself owner of that bug, that also means you
> engage yourself on a resolution sooner than later (even if I do fail
> applying that to myself...).
>> #2 Use tag based workflow
>> One lesson from github projects, is the github tracker has no workflow.
>> Issues are openned or closed. Workflow has to be invented by every team
>> based on a set of tags. Sometimes that's annoying, but often times it's
>> super handy, because it allows the tracker to change workflows and not
>> try to change the meaning of things like "Confirmed vs. Triaged" in your
>> mind.
>> We can probably tag for information we know we need at lot easier. I'm
>> considering something like
>> * needs.system-version
>> * needs.openstack-version
>> * needs.logs
>> * needs.subteam-feedback
>> * has.system-version
>> * has.openstack-version
>> * has.reproduce
>> Some of these a bot can process the text on and tell if that info was
>> provided, and comment how to provide the updated info. Some of this
>> would be human, but with official tags, it would probably help.
> The tags you propose seem to me related to an "Incomplete" vs.
> "Confirmed" state of the bug.
> If I'm not able to triage the bug because I'm missing information like
> the release version or more logs, I put the bug as Incomplete.
> I could add those tags, but I don't see where a programmatical approach
> could help us.

We always want that information, and the odds of us getting it from a
user decline over time. When we end up looking at bugs that are year
old, it becomes a big guessing game on their relevancy.

The theory here is that tags like that would be applied by a bot
immediately after the bug is filed. Catching the owner within 5 minutes
of their bug filing with a response which is "we need the following"
means we should get a pretty decent attach rate on that information. And
then you don't have to spend 10 minutes of real human time realizing
that you really need that before moving forward.


Sean Dague

More information about the OpenStack-dev mailing list