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

[Leif Madsen]

Find below an email Russell Bryant had originally sent to the bug 
marshals mailing list (which presumably is highly out of date, hence the 
reason for my posting here). I was going through the bug tracker this 
morning seeing what I could do to get more involved in helping to mark 
existing bugs with appropriate information so that they could either be 
moved forward, or so that developers could better spend their time 
looking at better bug reports.

While doing that I remembered that I had seen a policy for bug marshals 
back in the day, but could not find it on Asterisk.org. Russell kindly 
sent me a copy and asked if I wouldn't mind reviewing and updating it. 
So I went through and made some minor changes. Here is the original 
email from Russell posted in May 2006, with modifications and updates by me.

Please provide any feedback to this thread and once the majority of 
people are happy with it, we'll get it posted up to asterisk.org and 
linked from the bug tracker.

Thanks!
Leif.

----------

Greetings everyone,

Toward the beginning of the lifetime of the 1.2 release, I sent out an 
email with some thoughts regarding development process changes that I 
thought would make us more efficient at maintaining releases.

Part of my plan was about our usage of Mantis.  There is no definition 
for what all of the various statuses mean.  I wrote up a proposed list 
to try to define what they all mean so that we can take better advantage 
of them.  We never really went anywhere with it so I'd like to bring it 
up again.

Here is the workflow description I came up with that I would like to 
propose. Please provide your thoughts so that we can come up with 
something to make official and post on asterisk.org.

Please note that I am only trying to  come up with a way to take 
advantage of the status values we have in place in Mantis today.  I 
realize it is possible to configure custom status values, but it is kind 
of a pain.  I think it would be a good start to just standardize the use 
of what we have today.


BUG TRACKER WORKFLOW

The workflow in the bug tracker should be handled in the following way:

1) A bug is reported and is automatically placed in the 'new' status.

2) The Bug Marshall team should go through bugs in the 'new' status to 
determine whether the report is valid (not a duplicate, hasn't already 
been fixed, not a Digium tech support issue, etc.).  Invalid reports 
should be set to 'closed' with the appropriate resolution.  Categories 
and descriptions should be corrected at this point.  Bug Marshals should 
review patches for formatting issues and basic coding guidelines violations.

3) At this point, the next step is determined whether the report is 
about a bug or a submission of a new feature[Note1]:

      a) BUG: A bug should be moved into the status 'pending release 
branch'.  At this point, it must be determined whether this bug is 
present in the release branch.  Once a patch has been accepted into the 
release branch to fix the issue, the committer should use svnmerge to 
pull the fix into the trunk.
      If a different patch is needed to fix the bug in the trunk, a 
'block' should be put on the appropriate revision so that svnmerge does 
not try to merge that revision into the trunk in the future.  If a patch 
for the trunk is available, it should be merged.  Otherwise, the issue 
should be placed in the 'confirmed' status to await a patch for the trunk.
      Once the bug has been fixed in the appropriate places, it should 
be taken to the 'closed' status with the appropriate resolution.[Note2]

      b) FEATURE: A new feature should be placed in the 'acknowledged' 
status pending has passed basic formatting and code review, it should be 
placed in the  'ready for testing' status.  Once the feature has been 
acknowledged by one or more testers (at the bug marshalls discretion), 
the features status can be changed to 'confirmed'. Once a feature makes 
it to 'confirmed', it will be reviewed for inclusion in the trunk.  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]

4) If at any point in the workflow, an issue requires feedback from the 
original poster of the issue, the status should be changed to 
'feedback'.  Once the required information has been provided, it should 
be placed back in the appropriate point of the workflow.

5) If at any point in the workflow, a developer or bug marshall would 
like to take responsibility for doing the work that is necessary to 
progress an issue, the status can be changed to 'assigned'.  Once these 
changes have been completed, it can be placed back in the appropriate 
place in the workflow.

WORKFLOW SUMMARY

NEW: This issue is awaiting review by bug marshals.  Categorization and
summaries should be fixed as appropriate.  Initial code review for 
formatting and coding guidelines issues need to be done.

PENDING RELEASE BRANCH: This issue is considered a possible bug in the 
release branch.  It must be fixed in the release branch if it is 
appropriate to do so.

ACKNOWLEGED: This is an issue that only relates to the trunk, but is 
awaiting initial code review.

READY FOR TESTING: This is an issue which has a patch that is waiting 
for testing feedback from the community.

CONFIRMED: The patch associated with this issue has passed initial 
formatting and code review and has been tested if needed.  It is 
awaiting review for inclusion in the trunk.

FEEDBACK: This issue requires feedback from the poster of the issue 
before any additional progress in the workflow can be made. This may 
include providing additional debugging information, or a backtrace with 
DONT_OPTIMIZE enabled for example.

ASSIGNED: A developer or bug marshall has taken responsibility for 
taking the necessary steps to move forward in the workflow.  Once the 
issue is ready to be reviewed and feedback provided, it should be placed 
back into the appropriate place of the workflow.

RESOLVED: A resolution for this issue has been reached.  This issue 
should immediately be CLOSED.

CLOSED: No further action is necessary for this issue.

Notes:

1) Consult the release branch commit policy for help in deciding whether 
a patch should go into the queue for review in the release branch.  If 
there is any doubt, a report should be placed in the 'pending release 
branch' status and assigned to one of the release branch maintainers. 
The maintainers will make the decision whether this change will be 
accepted into the release branch.

2) The bug tracker now has the ability to monitor the
commits list, and if the commit message contains something like, "closes 
issue 9999", the bug will be automatically closed.

RELEASE BRANCH COMMIT POLICY

The code in the release branch should be changed as little as possible. 
  The only time the release branch will be changed is to fix a bug.  New 
features will never be included in the release branch unless a special 
exception is made by the release branch maintainers.

Sometimes it is difficult to determine whether a patch is considered to 
fix a bug or if it is a new feature.  Patches that are considered code 
cleanup, or to improve performance, are NOT to be included in the 
release branch.  Performance issues will only be considered for the 
release branch if they are considered significant, and should be 
approved by the maintainers.

If there is ever a question about what should be included in the release 
branch, the maintainers should be allowed to make the decision.


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