Open Stack

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.

I agree with you Ben. While I was running this query for old bug, I've
stopped so bugs after March of this year won't be modified (let me
know if that's the case, then I'll fix it).

A grace period of 7 days is a good idea maybe.

> 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...
>
>
>>
>> #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.
>>
>> #3 machine assisted functional tagging
>>
>> I'm playing around with some things that might be useful in mapping new
>> bugs into existing functional buckets like: libvirt, volumes, etc. We'll
>> see how useful it ends up being.
>>
>> #4 reporting on smaller slices
>>
>> Build some tooling to report on the status and change over time of bugs
>> under various tags. This will help visualize how we are doing
>> (hopefully) and where the biggest piles of issues are.
>>
>> The intent is the normal unit of interaction would be one of these
>> smaller piles. Be they the 76 libvirt bugs, 61 volumes bugs, or 36
>> vmware bugs. It would also highlight the rates of change in these piles,
>> and what's getting attention and what is not.
>>
>>
>> This is going to be kind of an ongoing experiment, but as we currently
>> have no one spear heading bug triage, it seemed like a good time to try
>> this out.
>>
>> Comments and other suggestions are welcomed. The tooling will have the
>> nova flow in mind, but I'm trying to make it so it takes a project name
>> as params on all the scripts, so anyone can use it. It's a little hack
>> and slash right now to discover what the right patterns are.
>>
>>         -Sean
>>
>
> __________________________________________________________________________
> 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



-- 
Emilien Macchi