On Wed, Jun 28, 2017 at 7:33 AM, Ben Nemec <openst...@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. Thanks, > >> >> #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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev