[openstack-dev] [nova] bug expiration
kchamart at redhat.com
Thu Apr 2 09:54:05 UTC 2015
On Thu, Apr 02, 2015 at 11:32:44AM +0200, Thierry Carrez wrote:
> Sean Dague wrote:
> > I just spent a chunk of the morning purging out some really old
> > Incomplete bugs because about 9 months ago we disabled the auto
> > expiration bit in launchpad -
> > https://bugs.launchpad.net/nova/+configure-bugtracker
> > This is a manually grueling task, which by looking at these bugs, no one
> > else is doing. I'd like to turn that bit back on so we can actually get
> > attention focused on actionable bugs.
> > Any objections here?
> No objection, just a remark:
> One issue with auto-expiration is that it usually results in the
> following story:
> 1. Someone reports bug
> 2. Triager notices NEW bug, asks reporter for details, sets INCOMPLETE
> 3. Reporter provides details
> 4. Triager does not notice reply on bug since they ignore INCOMPLETE
> 5. Bug expires after n months and disappears forever
> 6. Reporter is frustrated and won't ever submit issues again
> The problem is of course at step 4, not at step 5. Auto-expiration is
> very beneficial if your bug triaging routine includes checking Launchpad
> for "INCOMPLETE bugs with an answer" regularly. If nobody does this very
> boring task, then auto-expiration can be detrimental.
This is an excellent point.
A reporter takes time to file a bug, it should not be mindlessly expired
via a bot (as "Invalid" rationale) without even any priliminary
investigation in the first place.
Unfortunately, I see most attention is only on refactoring or on
half-baked shiny new features, which fall apart if you sneeze. Perils of
> Is anyone in Nova checking for "INCOMPLETE bugs with an answer" ? That's
> task 4 in https://wiki.openstack.org/wiki/BugTriage ...
I doubt that, I only see Sean take up this drudgery most times. I should
admit, I try sometimes, but just feel overwhelmed with the sheer numbers
and get distracted with other work.
PS: On a side note, I'd wish Launchpad (or the upcoming Storyboard) has
a state like "INSUFFICIENT_DATA" instead of the current, lousy,
"Invalid" state (using it as a blanket rationale for most bugs we want
to close). A bug can be _valid_ but might not have sufficient data for
any no. of reasons, it ought to be closed, accurately, as
"INSUFFICIENT_DATA" not "Invalid".
More information about the OpenStack-dev