Once a major/minor release has reached the Stable phase in the Development Cycle the processes and procedures for development change. The most immediate thing to notice is that the development is no longer driven by the Development team when the Stable phase is reached. As soon as the major/minor release is declared stable all future development on that release is driven by the Bug Squad. It is important to understand the way we think about Maintenance releases because one of the things that our community depends upon is stability. Stability is born of a rigorous testing process and accountability. This document will outline the procedures and processes for maintaining a Joomla! major/minor release.
People will notice that the content of this document look a lot like a description of the former Quality and Testing team. That is absolutely true because the main discussion here is about the Quality processes for Joomla! The main difference is the way the Bug Squad is organised compared to the former Quality and Testing team, but they strive to reach the same goals.
Once a release has been declared stable, all bugs and artifacts are to be tracked in our official tracker on the Joomla! GForge site: []. Having a single place for confirmed issue tracking provides us all with a simple system of accountability. The following flowchart provides a very rough description of how the issue tracking process is defined.
<image goes here>
There are some important areas that describe specific areas in more detail, topics are:
The process is started in one of two ways: the bug is added to the tracker, or a user reports the bug in the Quality and Testing forum for the given major/minor release.
If an issue is reported on the forums it is the Bug Squad's responsibility to verify the issue and add it to the Joomla Tracker. The Bug Squad member who evaluates the issue should modify the thread on the forum according to what action was taken.
If the issue was reported directly in the tracker then it is the Bug Squad team's responsibility to verify that the issue is in fact a bug. As part of this process they may open a discussion thread in the appropriate forum.
Once the bug has been verified and assigned it is the responsibility of the Development Working Group to resolve the issue.
Once the issue has been solved the developer will change the status of the bug to “Pending” and leave any comments/notes about the given issue for the tester. These comments/notes may include other aspects of the code base that might be affected by the fix and should be thoroughly checked for potential issues.
The Bug Squad member who assigned the bug originally should then retest the system after the bug has been fixed and state set to “Pending” to verify that the issue has in fact been resolved – also testing any other affected sections noted by the developer.