[openstack-dev] [nova] bug expiration

Sean Dague sean at dague.net
Thu Apr 2 10:45:36 UTC 2015


On 04/02/2015 06:33 AM, James Bottomley wrote:
> On Thu, 2015-04-02 at 11:32 +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.
>>
>> Is anyone in Nova checking for "INCOMPLETE bugs with an answer" ? That's
>> task 4 in https://wiki.openstack.org/wiki/BugTriage ...
> 
> This actually looks to be a problem in the workflow to me.
> 
> The OpenStack Incomplete/Confirmed seem to map roughly to the bugzilla
> Need Info/Open states.  The difference is that in bugzilla, a reporter
> can clear the Need Info flag.  This is also what needs to happen in
> OpenStack (so the reporter doesn't need to wait on anyone looking at
> thier input to move the bug on).
> 
> I propose allowing the reporter to move the bug to Confirmed when they
> supply the information making it incomplete.  If the triager thinks this
> is wrong, they can set it back to incomplete again.  This has the net
> effect that Incomplete needs no real review, it marks bugs the reporter
> doesn't care enough about to reply... and these can be auto expired.
> 
> This would make the initial state diagram
> 
> 
> +---+    Review     +----------+
> |New|-------------->|Incomplete|
> +---+               +----------+
>   |                     ^   |
>   |    Still Needs Info |   | Reporter replies
>   |                     |   v
>   |     Review      +---------+
>   +---------------->|Confirmed|
>                     +---------+
> 
> 
> James

Reporters can definitely move it back to New, which is the expected
flow, that means it gets picked up again on the next New bug sweep.
That's Step #1 in triaging (for Nova we've agressively worked to keep
that very near 0). I don't remember if they can also move it into
Confirmed themselves if they aren't in the nova-bugs group, though that
is an open group.

Mostly the concern is people that don't understand the tools or bug
flow. So they respond and leave in Incomplete. Or it's moved to
Incomplete and they never respond because they don't understand that
more info is needed. These things sit there for a year, and then there
is some whiff of a real problem in them, but no path forward with that
information.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list