[asterisk-dev] [policy] Bug Tracker Workflow Discussion

[Leif Madsen]

Tilghman Lesher wrote:
> On Monday 11 August 2008 09:07:26 Leif Madsen wrote:
>> 3) The next step is to determine whether the report is about a bug or a
>> submission of a new feature:
>>
>>       a) BUG: A bug should be moved into the status 'acknowledged'. The
>> bug may also be assigned to a developer for the creation of the initial
>> patch, or review of the issue. Once a patch has been created for the
>> issue and attached, the issue can then be moved to the 'confirmed'
>> status. At this point initial code review and discussion about the patch
>> will take place. Once an adequate amount of support for the
>> implementation of the patch is acquired, then the bug can be moved to
>> the 'ready for testing' status for wider testing by the community. After
>> the testing phase is complete and it appears the issue is resolved, the
>> patch can be committed by a developer and closed.
>>
>>       b) FEATURE: As new features should be filed with a patch, it can
>> be immediately moved to the 'confirmed' status, making it ready for
>> basic formatting and code review. From there any changes to style or
>> feel of the patch based on feedback from the community can be discussed,
>> and changes to the patch made. It can then be moved forward to the
>> 'ready for testing' status. Once the feature has been merged, or a
>> decision has been made that it will not be merged, the issue should be
>> taken to 'closed' with the appropriate resolution.[Note2]
> 
> I'd like to note that the statuses as noted here are in fact the reverse of
> the previous policy, and I'd like to suggest that we continue the previous
> policy, that features are acknowledged and bugs are confirmed.
> Additionally, I'd prefer that before bugs are confirmed, we either have a
> repeatable bug (perhaps steps to reproduce) or else we have enough
> information in the issue (backtraces, valgrind output, requested debug,
> etc.) to figure out what the problem is.  A good number of issues we ask,
> beg, and plead for more information, to which we get stony silence, after
> which we close the bug.  Sometimes closing the issue gets the reporter
> to respond; sometimes, though, we're left with a single report and no way to
> track down the issue.

In my head, the words themselves of 'acknowledged' and 'confirmed' seem 
to make more sense for the description I've documented above. In 
addition, the order/colour assigned to those statuses in the bug tracker 
seem to also reflect my description better. Not that I'm totally opposed 
to changing it around. I'm not even sure if the 'acknowledged' and 
'confirmed' statuses have been actively used...

I do agree that enough information needs to be done in the triage stage 
before moving the bug to acknowledged -- this is actually the point of 
creating these bug guidelines. The idea is to relieve the developers 
from having to deal with looking at bugs which have not had enough 
information from the original poster.

I suppose I need to slightly reword the above description then in order 
to make it a bit more obvious that the bug should move between 'new' and 
'feedback' until an appropriate amount of triage has been accomplished 
before moving it to 'acknowledged'.

> In other words, the "confirmed" status should mean that enough triage has been
> performed for a developer to take control of the issue.

I would agree with this, except that I would prefer to use 
'acknowledged' instead of 'confirmed' for that status, based on the 
description above.


-- 
Leif Madsen
http://www.leifmadsen.com
http://www.oreilly.com/catalog/asterisk