Actions

Difference between revisions of "Developer Area/Bug Status"

From Mahara Wiki

< Developer Area
(→‎Bug importance: refactor this section to make it more readable)
(→‎Bug milestone: rewrite the milestone section to match the current policy)
Line 17: Line 17:
 
== Bug milestone ==
 
== Bug milestone ==
  
The milestone should always point to the next planned release milestone on the appropriate branch. Say, if the bug affects 1.4_STABLE release,the milestone should point to branch 1.4.x; if the the bug is actually a new feature on the master that is not relevant to previous release, then the milestone should point to next upcoming release. For the both of these cases above the bug status should remain as "Fix committed" once the bug is merged to master. When release is out, the bug status will be flicked to "Fix released". '''The situation when the milestone is missing but the bug status is "Fix committed" should be avoided'''. It makes the bug not listed anywhere and at the time of the actual release, its status will not be updated and the bug will not be listed in the release notes.
+
The milestone is used for three main things:
  
However, there is a single case when the bug may be omitted from the milestone. When the bug fix is not applied to the stable releases, but fixes the feature that has been previously introduced to master branch and is not relevant to previous stable release. In this case the bug can be marked as "Fix released" and milestone can be omitted. The feature itself will retain "Fix committed" status until next release and should point to next release milestone. This will reduce the noise in the release notes, as the new feature will be listed in the notes, but there is no much sense to list bug fixes applicable to this new feature until it is released.
+
# as a TODO list for an upcoming release
 +
# as a record of when a bug was fixed
 +
# as an extended changelog for a given release
  
To sum up what is said above:
+
'''Fix committed''': When a bug is in the "fix committed" state, it needs a milestone (no exceptions) to indicate the first release it will be part of. For example:
* We must mark ALL new features and ALL bug fixes that apply to previous stable releases against the appropriate milestone.
+
* If you fix a bug in '''1.4_STABLE''' and 1.5.0 is not released yet, then you'd use a milestone of 1.4.1 (that being the next stable release) because we assume that 1.5.0 will have everything that the other stable releases have.
* All new features and bug fixes applicable to previous releases should have "Fix committed" status until the release will be out.
+
* If you fix it in '''1.3_STABLE''' and '''1.4_STABLE''', then it needs two milestones: 1.3.7 and 1.4.1.
* We omit from the milestone bugs that don't apply to the stable releases and fix the features that has been previously introduced to master branch only (after the last stable branch has been created), in which case once the fix is merged to master, the bug status must be updated directly to "Fix released" (with no milestone).
+
* If you only fix it on the '''master''' branch, then use 1.5.0 as the milestone since it won't be in any releases until then.
 +
 
 +
'''Fix released''': If a bug is in the "fix released" state then it usually has a milestone as described above in the "fix committed" section. The exception to this is when a bug moves from '''in progress''' to '''fix released''' because the bug has never affected any of the released versions of Mahara. In this case, it would be irrelevant to users of stable versions from a changelog point of view.
 +
 
 +
'''Triaged''', '''confirmed''', '''in progress''': If a bug is not yet fixed but is in one of the intermediate states, then the milestone may or may not be set:
 +
* if the release manager wants something to be fixed before a given release, the milestone will be set to that release
 +
* if a developer volunteers to fix something before a given release, they can set the milestone accordingly
 +
* otherwise, if it's just a bug, we leave the milestone '''unset''' to avoid putting too many tasks on the "release TODO list"
  
 
== Bug importance ==
 
== Bug importance ==

Revision as of 12:05, 19 August 2011

The status, priority, milestone, tags in Launchpad are used by Mahara developers for effective bug management. This page describe the current use of these features.

Bug status

The bug status reflects the current state of the bug. When the new bug is reported it obtains "New" status automatically (unless specified otherwise) and then usually goes through a number other statuses depending on developers actions and decisions. The list below describe each of the statuses and provides useful hints on status chnages.

  • New - The status field is automatically set to "new" when a bug is created.
  • Triaged - 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.
  • Confirmed - 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.
  • Invalid , Wont fix, 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.
  • 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, or submitted for revision should not be marked as "Fix Committed" until they appear in the master (or stable) branch from which releases are created (which will happen when the change on revision system is marked as merged).  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.
  • Fix Released - 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.

Bug milestone

The milestone is used for three main things:

  1. as a TODO list for an upcoming release
  2. as a record of when a bug was fixed
  3. as an extended changelog for a given release

Fix committed: When a bug is in the "fix committed" state, it needs a milestone (no exceptions) to indicate the first release it will be part of. For example:

  • If you fix a bug in 1.4_STABLE and 1.5.0 is not released yet, then you'd use a milestone of 1.4.1 (that being the next stable release) because we assume that 1.5.0 will have everything that the other stable releases have.
  • If you fix it in 1.3_STABLE and 1.4_STABLE, then it needs two milestones: 1.3.7 and 1.4.1.
  • If you only fix it on the master branch, then use 1.5.0 as the milestone since it won't be in any releases until then.

Fix released: If a bug is in the "fix released" state then it usually has a milestone as described above in the "fix committed" section. The exception to this is when a bug moves from in progress to fix released because the bug has never affected any of the released versions of Mahara. In this case, it would be irrelevant to users of stable versions from a changelog point of view.

Triaged, confirmed, in progress: If a bug is not yet fixed but is in one of the intermediate states, then the milestone may or may not be set:

  • if the release manager wants something to be fixed before a given release, the milestone will be set to that release
  • if a developer volunteers to fix something before a given release, they can set the milestone accordingly
  • otherwise, if it's just a bug, we leave the milestone unset to avoid putting too many tasks on the "release TODO list"

Bug importance

Importance is highly subjective, but here are some rough guidelines for how we use them in Mahara:

  • Critical: generally reserved for things that make the software unusable or pose a serious security risk for people running it. These are bugs where we drop everything we are doing to address them first.
  • High: most of the bad bugs that inconvenience people.
  • Medium: the default priority.
  • Low: minor bugs that will probably not get fixed unless someone picks it up and submits a patch.
  • Wishlist: for new features or for enhancements (i.e. things that are not really bugs).

Tags

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.

Relevant links