Difference between revisions of "Joomla! Maintenance Procedures"

From Joomla! Documentation

(fix tracker link)
 
(19 intermediate revisions by 7 users not shown)
Line 1: Line 1:
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.
+
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 a [[Maintenance Release]] 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 ([[Maintenance Release]]), all bugs and issues are to be tracked in our official [http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Joomla! Tracker] on the [http://www.joomlacode.org Joomla! GForge site]. Having a single place for confirmed issue tracking provides us all with a simple system of accountability.  
  
Once a release has been declared stable, all bugs and artifacts are to be tracked in our official tracker on the Joomla! GForge site: [[http://www.joomlacode.org]]. 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.
+
The maintenance procedures have the following stages :
 +
* [[Bug Tracking Process#Reporting Issues|Reporting Issues]]; We keep track on the open issues in the tracker, but issues can be reported in two ways: from the forum or directly into the tracker.
 +
* [[Bug Tracking Process#Resolving Issues|Resolving Issues]]; Once an issue is confirmed, there are several ways it can get solved. First members from the [[Development Team]] can work on solving the issue, but also community members can send in patches. The general way of working is: create patch, test patch, commit patch.  
  
[[Image:bughandlingprocess.png]]
+
The maintenance procedures implement the Quality processes for Joomla!. This process differs only during the development stage of a major release or a minor release in the [[Bug Tracking Process#Resolving Issues|resolving issues]] process. In maintenance releases we work with patches, and within the [[Development Cycle]] of a major release or a minor release developers will fix issues directly in the trunk until the codebase reaches a stage of [[Development Cycle|Release Candidate]].
 
+
<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>
There are some important areas that describe specific areas in more detail, topics are:
 
* [[Joomla Tracker]] describes all details about the tracker we use. This is a very detailed description (from how to register to all field details that are used).
 
* The [[Joomla Forum]] is an important area where the community members can report issues or just ask questions. You will find a detailled description here about the way the forum is organized for the Joomla! releases.
 
 
 
 
 
== Reporting issues ==
 
 
 
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.
 
 
 
=== Issues reported on the forums ===
 
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.
 
 
 
* '''Invalid'''. If the report is determined to either not be an bug or a known issue this should be reflected in the thread.
 
* '''Valid'''. If the report is verified as a bug and was added to the tracker the forum thread should reflect that as well as have a link added to the tracker artifact.
 
 
 
=== Issues reported on the tracker ===
 
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.
 
 
 
*'''Invalid'''. At that point if the report is invalid the issue is closed on the tracker (status ''"closed"'').
 
*'''Valid'''. If, however the issue is a bug than the [[Bug Squad]] member should assign the bug to a developer and provide any notes about the issue that are relevant in the comments box. Any missing information that is relevant should be filled in as well.
 
 
 
== Resolving issues ==
 
Once the bug has been verified and assigned it is the responsibility of the Development Working Group to resolve the issue.
 
 
 
* '''Able'''. If the assigned developer is able to fix the bug, it should be fixed as soon as possible.
 
* '''Unable'''. If the assigned developer is unable to fix the bug for some reason, he/she should inform the [[Development team]] lead for the given release that he/she is unable to get to the bug at this time and it should be re-assigned. Also, if the assigned developer is known to be unavailable the development lead should re-assign the bug. If the bug must be re-assigned, it is the development lead's job to reassign the bug or deal with it personally.
 
 
 
== Report resolved issues ==
 
 
 
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.
 
 
 
== Verify the results ==
 
 
 
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.
 
 
 
* '''Re-Submit'''. If there are still problems then the [[Bug Squad]] member would change the status back to open and contact the developer to better communicate the problem.
 
* '''Close'''. If, however the issue is resolved then the [[Bug Squad]] member and ONLY the [[Bug Squad]] member changes the bug state to fixed in SVN.
 

Latest revision as of 15:31, 7 June 2009

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 a Maintenance Release 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.

Once a release has been declared stable (Maintenance Release), all bugs and issues are to be tracked in our official Joomla! Tracker on the Joomla! GForge site. Having a single place for confirmed issue tracking provides us all with a simple system of accountability.

The maintenance procedures have the following stages :

  • Reporting Issues; We keep track on the open issues in the tracker, but issues can be reported in two ways: from the forum or directly into the tracker.
  • Resolving Issues; Once an issue is confirmed, there are several ways it can get solved. First members from the Development Team can work on solving the issue, but also community members can send in patches. The general way of working is: create patch, test patch, commit patch.

The maintenance procedures implement the Quality processes for Joomla!. This process differs only during the development stage of a major release or a minor release in the resolving issues process. In maintenance releases we work with patches, and within the Development Cycle of a major release or a minor release developers will fix issues directly in the trunk until the codebase reaches a stage of Release Candidate.