Actions

Difference between revisions of "Developer Area/Bug Status"

From Mahara Wiki

< Developer Area
(RCs don't count for "fix released")
(milestone must be updated when using "fix committed")
Line 6: Line 6:
 
# "Invalid", "wont fix", and "opinion" are all statuses that effectively close the bug.  "Invalid" is for things we don't really think are bugs at all, or maybe they're bugs but not bugs in Mahara.  "Won't fix" is self-explanatory.  "Opinion" is a softer version of "won't fix", and indicates to the reporter that there is reasonable disagreement about whether the bug is a bug or should be fixed (and invites more comments).
 
# "Invalid", "wont fix", and "opinion" are all statuses that effectively close the bug.  "Invalid" is for things we don't really think are bugs at all, or maybe they're bugs but not bugs in Mahara.  "Won't fix" is self-explanatory.  "Opinion" is a softer version of "won't fix", and indicates to the reporter that there is reasonable disagreement about whether the bug is a bug or should be fixed (and invites more comments).
 
# "In progress" is for bugs which are currently being worked on.
 
# "In progress" is for bugs which are currently being worked on.
# "Fix committed" is for when a fix is committed to git.  Bugs which have been fixed only in the commit author's local branch or personal clone repository should not be marked as Fix Committed until they're fixed in the master (or stable) branch from which releases are created.  Any time a bug is marked as "fix committed", the milestone field should also be updated to the next planned release milestone on the appropriate branch, and if the bug is still unassigned, it should be assigned to whoever provided the patch.
+
# "Fix committed" is for when a fix is committed to git.  Bugs which have been fixed only in the commit author's local branch or personal clone repository should not be marked as Fix Committed until they're fixed in the master (or stable) branch from which releases are created.  Any time a bug is marked as "fix committed", '''the milestone field must also be updated''' to the next planned release milestone on the appropriate branch, and if the bug is still unassigned, it should be assigned to whoever provided the patch.
 
# Status is flipped to "Fix Released" once there is a stable release (i.e. a tarball) which includes the fix (alphas, betas and release candidates don't count).
 
# Status is flipped to "Fix Released" once there is a stable release (i.e. a tarball) which includes the fix (alphas, betas and release candidates don't count).
  

Revision as of 22:27, 21 June 2011

Current use of status / priority / milestone in Launchpad by Mahara developers:

  1. The status field is automatically set to "new" when a bug is created.
  2. Once we've looked at a bug and decided on a priority and a milestone, it's changed to "triaged". Triaged is for bugs we haven't tried to reproduce.
  3. Status is changed to "confirmed" once we've been able to reproduce it, or to "incomplete" if we need more information to be able to reproduce it.
  4. "Invalid", "wont fix", and "opinion" are all statuses that effectively close the bug.  "Invalid" is for things we don't really think are bugs at all, or maybe they're bugs but not bugs in Mahara.  "Won't fix" is self-explanatory.  "Opinion" is a softer version of "won't fix", and indicates to the reporter that there is reasonable disagreement about whether the bug is a bug or should be fixed (and invites more comments).
  5. "In progress" is for bugs which are currently being worked on.
  6. "Fix committed" is for when a fix is committed to git.  Bugs which have been fixed only in the commit author's local branch or personal clone repository should not be marked as Fix Committed until they're fixed in the master (or stable) branch from which releases are created.  Any time a bug is marked as "fix committed", the milestone field must also be updated to the next planned release milestone on the appropriate branch, and if the bug is still unassigned, it should be assigned to whoever provided the patch.
  7. Status is flipped to "Fix Released" once there is a stable release (i.e. a tarball) which includes the fix (alphas, betas and release candidates don't count).

Periodically the core development team will go through the open bugs, decide what should be fixed before the next release, and update the status and milestone fields accordingly.

Priority is highly subjective.  "Critical" should generally be reserved for things that make the software unusable or pose a serious security risk for people running it.  Most of the bad bugs that inconvenience people should be marked as "high" priority.  Distinguishing bugs from enhancement/feature requests is difficult in Launchpad, and we've overused the "Wishlist" priority which has a bit of a double meaning.  A bug might have been marked "wishlist" because it's not really a bug, but we might still feel it's very important to address, and tackle it before a medium-priority bug that doesn't affect many users.

We encourage the use of tags to group bugs together!  If you triage a bug and think it's easy, but you don't plan to fix it immediately, tag it as "bite-sized". If we get enough bite-sized bugs, we can list them on openhatch.org, or other sites that might encourage new contributors.