Huge thanks to Joshua Colp for mirroring services

Workflow Guidelines for Asterisk Open Source Issue Tracker

Share on Twitter Digg this story Click to view a printable version Thu, 24 Sep 2009 21:13:19 -0300

thumnail

The purpose of this document is to briefly describe the various statuses an issue can be placed in, and what that status means. In addition, the simple workflow and transition between statuses will be discussed.

Issue Status Definitions

New

The 'New' status is where all bugs start. This is an issue which has not received a review by a bug marshal to move it to an appropriate next status. Steps required to move to the next logical step include:

  • checking Category and Severity are set correctly


  • verifying the issue does not look like a support issue (if so, note the reporter should use the appropriate support channels, and change status to Closed)


  • determine that enough debugging information has been provided so that a developer can move the issue forward (e.g. on SIP issues, that the standard SIP debug and history, console output, and configuration file information has been provided, or in the case of a crash issue, that a proper backtrace has been provided)

If the necessary information has not been collected, then the issue should be moved to Feedback status, and the missing information be requested by the reporter*.

When all required information has been collected, the issue can be moved to the Acknowledged status.

(*) issues which remain in the Feedback status for more than 2 weeks without feedback from the reporter should be marked as Closed/Suspended

Acknowledged

The 'Acknowledged' status is the first step to issue resolution. It is an issue that has been filed correctly, the categorization and severity have been set, and that initial debugging information has been collected.

A developer may then review the issue tracker for Acknowledged issues and to determine whether additional information is necessary (i.e. that a crash issue with backtrace requires valgrind output, or other non-standard debugging feedback).

Issues may be moved to the next step in the workflow when the developer has either determined the issue is Confirmed, requires additional Feedback, is an issue that has already been resolved (or does not need to be resolved), in which case it should be Closed.

Confirmed

The 'Confirmed' status represents issues which have been verified as existing in the current branch(es), and has all necessary information to be accepted into Acknowledged status. The general qualifier for an issue being moved to Confirmed is more than one community member stating the issue exists.

Confirmed issues may also contain patches created by developers which need to be applied in order to gain further knowledge or debugging by the original reporter, or any other community member who has verified this issue as existing. The developer will then move the issue to Feedback status while waiting for information from the reporter(s).

Issues with patches that are candidates for inclusion into the various branches that should resolve the issue are to be moved to the Ready for Testing status.

Ready for Testing

'Ready for Testing' indicates issues which have patches available for testing by community members or the original reporter which should resolve the reported issue.

If the patch does not resolve the issue, then it should be placed back into Confirmed status until an additional patch can be created for testing.

If the patch resolves the issue, then it should be moved to the Ready for Review status.

Ready for Review

When an issue has a patch that has been tested by a community member and which resolves the originally reported issue, should then be moved to the Ready for Review status. Issues marked as Ready for Review should then either be reviewed by another developer prior to merging (if it is a non-invasive fix), or the patch should be placed on Reviewboard if it is a complicated or invasive fix.

If an issue has a reviewboard link, it should be placed in the Additional Information section of an issue, and the marker [review] prefixed to the issue title.

Resolved

The Resolved status is rarely used directly by manual intervention, but
rather is utilized by svnbot and other automated methods prior to an
issue being closed.

Feedback

Feedback is used when an issue is awaiting information from the original reporter, or other active members of the community in the issue. Issues which remain in the feedback state longer than 2 weeks without feedback from any active participants, and which cannot be moved without, are to be Closed and marked as suspended.

License Required

License Required is used when a patch has been attached to an issue, but which is currently in the License Pending state, or has been rejected and is awaiting the reporter to resign the license.

Assigned

Issues marked as Assigned are the responsibility of the assigned developer, typically because they contain some sort of special knowledge required to resolve the issue, or because they have decided to take responsibility for moving the issue to resolution.

Closed

Issues which have a resolution are marked as Closed. There are several resolutions that a Closed issue can contain, such as Fixed, Won't Fix, Duplicate, or Suspended. Issues that have been Closed manually should have an appropriate resolution set such as Suspended or Won't Fix, along with a note indicating why the issue was Closed.

If the issue is being closed due to a lack of feedback, the resolution should be Suspended, and a note indicating the issue was closed due to a lack of feedback, and that it will be reopened upon request if the reporter can provide the necessary information to move the issue forward again.




Typical Workflow

The typical workflow of an issue is as follows:

Brief

New > Feedback(*) > Acknowledged > Confirmed > Ready for Testing > Ready for Review > Closed (commited, closed by svnbot)

(*)Optional status used when not enough information provided to move to Acknowledged.

Verbose

  • Issue is filed by a community member. All issues will start in the status New.


  • An issue marshal then performs triage on New issues and determined if they are valid issues (non-support), have been correctly categorized, have the necessary debugging information, etc…

    • Issues without the necessary information are moved to Feedback


    • Issues that are support, or feature requests without patches, are Closed


    • Issues that have all the necessary debugging information to move forward are Acknowledged


  • After an issue has been moved to the Acknowledged state, then a developer will review to determine if the issue exists, and if so, to move it to the Confirmed state. If additional information is required, the issue may be moved to Feedback state.


  • An issue reaches the Confirmed state when the issue has been verified to exist. Issues that are Confirmed may also contain patches that provide additional debugging information.


  • Issues that have patches that require testing and feedback from the community are then placed in the Ready for Testing status.


  • Once a patch has been tested and confirmed to resolve the issue, we change the status to Ready for Review.


  • An issue that is Ready for Review needs to be looked over by a developer, or placed on Reviewboard (for larger patches) prior to being commited. Issues that are in Ready for Review are typically ready, or nearly ready to be committed.


  • Once an issue has been commited, svnbot will then Close the issue if the correct keywords are used in the commit message (see Guidelines for Commit Messages)


You haven't voted yet! Vote:
Current Rating: 6/10 (1 votes)

Comments (Click to post)

Comments
Name:
Subject:
Website:
Message: 

Similar Articles (Based on Title)

CALEA enforcement guidelines according to Comcast - October 17, 2007
Kris has posted a link to the ComCast manual for CALEA compliance which was posted to SourceForge.

*-Dev: New jitterbuffer and Packet Loss Concealment preview/prototype patch available in tracker. - January 21, 2005
Steve Kann has posted details of the latest patch added to the bugtracker.

About the bug tracker - February 25, 2005
Olle has posted a note about people posting support issues to the bug tracker. The main point of his mail is: don't do it!

*-Announce: New issue tracker for handling licensing issues for Asterisk, Zaptel and related projects - February 7, 2006
The Asterisk Development Team have posted details of a new issue tracker for Asterisk and Zaptel etc.

Asterisk projects now reporting to CIA tracker - January 3, 2007
Kevin Fleming has posted details of the availability of Asterisk Commits via RSS.

*-Dev: pseudo realtime and load issue - August 25, 2005
Steven Critchfield has posted details of a patch to reduce the risk of running Asterisk in pseudo realtime mode.

Security Issue in Asterisk trunk IMAP_STORAGE - June 26, 2007
Russell Bryant has posted details of a security issue in trunk.

Update on FBI Issue - Important - December 9, 2008
John Todd has sent a detailed note to the Asterisk developers list regarding the recent security release. Please post this wherever you can.

Testers Needed Issue 16965 DBGet response does not end with a Complete event - March 19, 2010
Ryan Bullock is looking for people to test a patch he has written to fix the DBGet Action.

Link: Open Source VoIP Ready For Its Close Up (Asterisk 1.0 article) - September 28, 2004
An article on internetnews about Asterisk 1.0 sent in by Greg Varga

NewsForge: Open source helps power SIP phone popularity (talks about Asterisk) - October 1, 2004
An article forwarded by Toby Mills which talks about Digium and Open Source


Original Content (C) 2004-2010 Matt Riddell
Back 5  Feed Add
to
Google Subscribe with Bloglines
Go to today

Icons by: FastIcon.com


Back to life
July 21, 2010 Average Vote: 10
Hey all - I am back online after some pretty big projects which have taken all my time. Will be updating the Asterisk news over the next few days.

Nerd Vittles: Building a Bluetooth Proximity Detection System with Asterisk
December 12, 2005 Average Vote: 10
The Nerd Vittles site has an article on proximity detection using Asterisk and a TomTom GPS

Automated Testing Update
July 30, 2010 Average Vote: 10
Russell Bryant has posted details of a new mailing list for automated testing of Asterisk and some information on the progress that has been made. There is no way to say how important I think this work is. It really makes a huge difference to Asterisk and the ability to use it in an enterprise environment. Really great work.

VoIP-Info: FFasterisk Video file converter
August 25, 2006 Average Vote: 10
The wiki has a link to a new piece of software for converting video to the format required for Asterisk.

Code Review: SRTP support for Asterisk
March 12, 2009 Average Vote: 10
Terry Wilson has moved his SRTP branch onto the Digium review board.

HumBug - Pre BETA Launch Registration
July 27, 2010 Average Vote: 10
Nir Simionovich has posted details of the beta of the new call analytics service.

Interview with BKW_
December 7, 2004 Average Vote: 10
We've finally completed our interview with BKW. Hope you like! :-)

SlashDot: GSM and Asterisk Integration
August 21, 2005 Average Vote: 10
There is a post up on SlashDot which talks about using cellphones with Asterisk.

Interview with Mark Spencer
November 26, 2004 Average Vote: 9.9
We have managed to get an interview with Mark Spencer AKA Markster. Mark Spencer is the creator of Asterisk and by far the most active developer.

Asterisk and Kamailio realtime integration tutorial
May 24, 2010 Average Vote: 9.9
Daniel-Constantin Mierla has posted a link to a tutorial on integrating Asterisk and Kamailio using realtime.

Asterisk IPv6 update
February 1, 2010 Average Vote: 9.8
Olle has posted an update on IPV6 in Asterisk and a link to a blog post of his.

Proposal for T.38 transparent gateway design in Asterisk
April 29, 2010 Average Vote: 9.8
Kevin Fleming has posted a proposed design for a transparent T.38 gateway for Asterisk:

Asterisk Monitoring with iPhone and iPod touch
February 12, 2010 Average Vote: 9.7
For the past couple of weeks I have been working on an app that allows you to monitor and restart Asterisk servers.

Monitoring Asterisk with Munin
January 7, 2010 Average Vote: 9.7
I had a few requests for these munin plugins after some discussion on one of the Asterisk lists and thought people might like them.

New Zealand Asterisk Voices
March 2, 2006 Average Vote: 9.7
Chris Hodgetts has posted details of recordings of Asterisk Sounds with a New Zealand accent.


Automated Testing Update
July 30, 2010
Russell Bryant has posted details of a new mailing list for automated testing of Asterisk and some information on the progress that has been made. There is no way to say how important I think this work is. It really makes a huge difference to Asterisk and the ability to use it in an enterprise environment. Really great work.

Asterisk 1.8.0-beta2 Now Available
July 28, 2010
The Asterisk Development Team has announced the release of Asterisk 1.8.0-beta2.

HumBug - Pre BETA Launch Registration
July 27, 2010
Nir Simionovich has posted details of the beta of the new call analytics service.

Branch Merging Changes
July 26, 2010
Russell Bryant has posted details of some changes to the way developers need to commit code to Asterisk because of the newly released 1.8 branch.

Asterisk 1.8.0-beta1 is Now Available
July 26, 2010
The Asterisk Development Team has announced the release of Asterisk 1.8.0-beta1. This release marks the beginning of the testing process for the eventual release of Asterisk 1.8.0.

Asterisk 1.6.2.10 Now Available
July 26, 2010
The Asterisk Development Team has announced the release of Asterisk 1.6.2.10.

Asterisk 1.4.34 Now Available
July 26, 2010
The Asterisk Development Team has announced the release of Asterisk 1.4.34.

AppleRaisin - AstDB over realtime
July 23, 2010
Olle has posted a note about his awesome AppleRaisin branch which provides the ability to store AstDB in realtime. This would make for a much simpler failover and clustering situation.

QueueMetrics 1.6.1 released
July 22, 2010
Lenz has posted a note to inform us that QueueMetrics version 1.6.1 has been released. This release offers a large number of bug fixes, misc improvements and new developements including hotdesking.

Asterisk 1.8 Branch Creation
July 22, 2010
Russell Bryant has posted a note to inform us of the creation of the 1.8 branch of Asterisk.