[openstack-dev] [nova] I'm going to expire open bug reports older than 18 months.
shoham.peller at stratoscale.com
Mon May 30 20:02:43 UTC 2016
I support Clint's comment, and as an example, only today I was able to
search a bug and to see it was reported 2 years ago and wasn't solved since.
I've commented on the bug saying it happened to me in an up-to-date nova.
I'm talking about a bug which is on your list -
I guess I wouldn't
been able to do so if the bug was closed.
On Mon, May 30, 2016 at 9:37 PM, Clint Byrum <clint at fewbar.com> wrote:
> (Top posting as a general reply to the thread)
> Bugs are precious data. As much as it feels like the bug list is full of
> cruft that won't ever get touched, one thing that we might be missing in
> doing this is that the user who encounters the bug and takes the time
> to actually find the bug tracker and report a bug, may be best served
> by finding that somebody else has experienced something similar. If you
> close this bug, that user is now going to be presented with the "I may
> be the first person to report this" flow instead of "yeah I've seen that
> error too!". The former can be a daunting task, but the latter provides
> extra incentive to press forward, since clearly there are others who
> need this, and more data is helpful to triagers and fixers.
> I 100% support those who are managing bugs doing whatever they need
> to do to make sure users' issues are being addressed as well as can be
> done with the resources available. However, I would also urge everyone
> to remember that the bug tracker is not only a way for developers to
> manage the bugs, it is also a way for the community of dedicated users
> to interact with the project as a whole.
> Excerpts from Markus Zoeller's message of 2016-05-23 13:02:29 +0200:
> > 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 .
> > You can spare bug reports if you leave a comment there which says
> > one of these (case-sensitive flags):
> > * CONFIRMED FOR: NEWTON
> > * CONFIRMED FOR: MITAKA
> > * CONFIRMED FOR: LIBERTY
> > 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:
> >  http://18.104.22.168:8082/bugs-dashboard.html#tabExpired
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev