Handle fixed verified issues

From Apache OpenOffice Wiki
Revision as of 08:07, 15 July 2009 by Thorstenziehm (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Proposal : Recheck of 'fixed/verified'-issues in Master builds isn't mandatory anymore

Current situation

It is defined [1] in the life cycle of a fixed issue (defects, enhancements, features or tasks) that the last step is to check the fix in a Master Build. After verification of the fix the issue has to be set to status 'closed'. The work flow is documented in the Issue Handling section [2] on http://qa.openoffice.org in the Bug Life Cycle document [3] on page 3.

This work flow guaranteed that a bug is found in the Master Build, when it is integrated by the following faults.

  1. The code contributions aren't checked-in (committed) in the source tree and the tested build is done on a local copy of the source. The changes are in the tested build (CWS) but isn't in the Master Build.
  2. The code contribution in one CWS overwrites a code contribution in another CWS. This exists when more than one CWS handles code in the same code areas and when they are integrated into (the same) Master. Then integration-conflicts (merge-conflicts) exists and these have to be fixed by a Release Engineer or the responsible developer. When the conflicts aren't fixed correctly changes from one CWS will win and the code of another CWS isn't integrated.
  3. If dependencies from one CWS break changes in another CWS. For example in one CWS incompatible API changes were integrated and in another CWS the older API is used. The functionality in each CWS works fine. But after integration the functionality on the second CWS is broken.

In all these cases the product can crash, because missing or wrong code should be used by some functions.

All cases weren't very often in the past releases of OOo. When we had such a situation the bugs were identified very quickly, because general functionality was broken on master completely. It wasn't needed to check a special issue for verification to identify the problem. The general agreement between QA project [4] and the QA team inside Sun is that less than 1% of all fixed issues could be broken in Master.

Currently (July 2009) there are more than 1650 fixed/verified issues open which have to be checked in a Master build before closing.

  • 178 with targets older than OOo 2.4 (before Mar. 2008)
  • 250 with target OOo 2.4.x (released Mar./Oct. 2008)
  • 502 with target OOo 3.0.x (released Oct. 08/ Jan. 09)
  • 265 with target OOo 3.1 (released May 09)
  • 483 with current targets (OOo 3.1.1 and OOo 3.2) and which are already integrated in Master

In the past years more than 4250 issues were fixed per year. All these issues have to be checked in Master. To address this high number of unclosed issues the QA project started with Issue-Hunting-Days where they are working in chats on closing such issues (in these chats ~50 issues are closed without any fault found). But also these events doesn't help to reduce the number of such issues dramatically. The effort is too high for the QA project and the benefit is low.


It isn't mandatory anymore to check each fixed/verified issue in a Master build. It is still needed to check all fixed issues (defects, enhancements, features or tasks) in CWS and set them to state 'fixed/verified'. If the owner, the submitter or someone else wants to check the issue in a Master build the issue will stay in this state for round about half a year. When the issues isn't closed in this time frame the issue will be closed automatically. This will be done by someone who has to be defined by the release status meeting. The issues should be closed automatically when 2 new released were done. This means when OOo 3.2 is released all 'fixed/verified' issues with target OOo 3.1 can be closed (quarterly releases).

The first step can be done by Thorsten Ziehm or Jörg Jahnke. In this step the opened 'fixed/verified' issues with targets older than or equal 2.4, 2.4.1, 3.0 and 3.0.1 will be closed. Issues with other targets which are in this state longer than March 2009 will be closed too. A text like 'This issue is closed automatically. When this issue isn't fixed in the current release, please reopen it.' should be added to each issue.


The owner of an issue and the whole QA project will win time for other work.


There is still a low risk to lower the quality of the product. General agreement with QA community and QA responsible inside Sun is that less than 1% of all fixed issues are broken in the Master. When something broke at integration of a CWS than the critical issues were identified without checking a special fixed/verified issue.


[1] : http://qa.openoffice.org/ooQAReloaded/Docs/QA-Reloaded-IssueHandlingOverview.html
[2] : http://qa.openoffice.org/ooQAReloaded/ooQA-IssueRules.html
[3] : http://qa.openoffice.org/issue_handling/workflowcharts/defect_triaging.pdf
[4] : http://qa.openoffice.org/servlets/ReadMsg?list=dev&msgNo=12513

Personal tools