[Openstack-operators] Fwd: [openstack-dev] [nova] I'm going to expire open bug reports older than 18 months.

Markus Zoeller mzoeller at linux.vnet.ibm.com
Fri May 27 13:25:49 UTC 2016

Maybe a few more words on this ML *why* I'm doing this. It all comes
down to a simple resource problem. Far more bug reports get filed than
solved. For the last 3 releases the numbers [1][2][3] are:

                    Kilo   Liberty   Mitaka
    Filed Bugs:     1144       926      968
    Resolved Bugs:   722       570      524

The unresolved bug reports accumulate over time. Finding people to work
on those is nearly impossible. Some of the reasons are:
* a lot of the bug reports don't provide clear steps to reproduce the
* information about the setup/configuration/version(s) is missing
* not enough developers with a deep knowledge of Nova and its history

>From my point of the view, the bug list should serve as a tool to
*improve* Nova. This doesn't work if it's impossible to have an overview
of the things that are broken. The more current the affected version of
Nova is, the more likely it is that it gets solved.

I don't see a benefit in leaving very old bug reports open when nobody
is working on it (again, a resource problem). Closing it (with "Won't
Fix") is explicit and easy to query. The information is not lost. This
does *not* mean we don't care about the reported issues. It's simply
just more than we can currently handle.


Regards, Markus Zoeller (markus_z)

On 24.05.2016 04:11, Tom Fifield wrote:
> FYI - if you have a bug that's been around forever in nova, please 
> follow Markus' instructions
> -------- Forwarded Message --------
> Subject: [openstack-dev] [nova] I'm going to expire open bug reports 
> older than 18 months.
> Date: Mon, 23 May 2016 13:02:29 +0200
> From: Markus Zoeller <mzoeller at linux.vnet.ibm.com>
> Reply-To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev at lists.openstack.org>
> To: openstack-dev at lists.openstack.org
> TL;DR: Automatic closing of 185 bug reports which are older than 18
> months in the week R-13. Skipping specific bug reports is possible. A
> bug report comment explains the reasons.
> I'd like to get rid of more clutter in our bug list to make it more
> comprehensible by a human being. For this, I'm targeting our ~185 bug
> reports which were reported 18 months ago and still aren't in progress.
> That's around 37% of open bug reports which aren't in progress. This
> post is about *how* and *when* I do it. If you have very strong reasons
> to *not* do it, let me hear them.
> When
> ----
> I plan to do it in the week after the non-priority feature freeze.
> That's week R-13, at the beginning of July. Until this date you can
> comment on bug reports so they get spared from this cleanup (see below).
> Beginning from R-13 until R-5 (Newton-3 milestone), we should have
> enough time to gain some overview of the rest.
> I also think it makes sense to make this a repeated effort, maybe after
> each milestone/release or monthly or daily.
> How
> ---
> The bug reports which will be affected are:
> * in status: [new, confirmed, triaged]
> * AND without assignee
> * AND created at: > 18 months
> A preview of them can be found at [1].
> You can spare bug reports if you leave a comment there which says
> one of these (case-sensitive flags):
> The expired bug report will have:
> * status: won't fix
> * assignee: none
> * importance: undecided
> * a new comment which explains *why* this was done
> The comment the expired bug reports will get:
>      This is an automated cleanup. This bug report got closed because
>      it is older than 18 months and there is no open code change to
>      fix this. After this time it is unlikely that the circumstances
>      which lead to the observed issue can be reproduced.
>      If you can reproduce it, please:
>      * reopen the bug report
>      * AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
>        Only still supported release names are valid.
>        valid example: CONFIRMED FOR: LIBERTY
>        invalid example: CONFIRMED FOR: KILO
>      * AND add the steps to reproduce the issue (if applicable)
> Let me know if you think this comment gives enough information how to
> handle this situation.
> References:
> [1]

More information about the OpenStack-operators mailing list