dev_process/bugzilla-use.php - gerrit/www.eclipse.org/projects - Git at Google

 <?php
 	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");

 $pageTitle 		= "Bugzilla Use";
 $pageKeywords	= "development process";
 $pageAuthor		= "Bjorn Freeman-Benson Nov 20/05";

 	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-after-definitions.php");
 ?>
     <div id="maincontent">
 	<div id="midcolumn">

 <h1>Bugzilla Use</h1>
 <p><i>version 028 - November 29, 2005</i></p>
 <p><a href="index.php">[This is one page of the larger document.]</a></p>
 <h2>Bugzilla</h2>

 <p>A common question new projects ask is &quot;how should we use Bugzilla
 effectively?&quot;. The <a href="http://www.bugzilla.org/docs/2.18/html/using.html">Bugzilla
 documentation</a> describes the basic mechanics and outlines the bug lifecycle
 that is designed into Bugzilla:</p>

 <p align="center"><img border="0" src="images/bzLifecycle.png" width="496" height="579"></p>

 <p>The Eclipse projects have different schemes for using Bugzilla, but a common one
 is as follows:</p>
 <ul>
   <li>Users &quot;own&quot;: component, version, platform, OS, severity,
     summary, and description</li>
   <li>The Committers &quot;own&quot;: status, resolution, and priority.</li>
   <li>Users may not change the Committer owned fields - this is enforced by
     social convention.</li>
   <li>Bugzilla provides a mechanism to watch another email address and
     developers are expected to use this to watch the component owner's address
     to monitor the incoming bugs for their projects/components.</li>
   <li>At the start of each day, each project/component team lead does bug
     triage. He or she assesses each NEW bug:
     <ul>
       <li>Validation
         <ul>
           <li> verify if the bug is really a bug or if it belongs to this component</li>
           <li>if the bug needs more information to be validated as a bug, add a request for more information/steps to reproduce, etc.
             The bug remains in the NEW state until enough information is received
             to validate it.<sup>1</sup></li>
           <li>if there is no response within a week, close the bug (RESOLVED
             INVALID or WONTFIX) telling the submitter to re-open once they have
             more info</li>
           <li>the bug may get moved to another component/product</li>
           <li>the bug may be a user problem, or may be intended behavior - these
             get annotated with the reason/information and RESOLVED to INVALID or WONTFIX
             or WORKSFORME (generally, INVALID means the report is just bogus,
             WORKSFORME means the report is not a problem, and WONTFIX is used for things
             that are valid requests, but that the team can't do).</li>
           <li>once a bug is validated, it goes to prioritization</li>
         </ul>
       </li>
       <li>Prioritization
         <ul>
           <li>If the bug is a feature request, change the severity to <i> enhancement</i></li>
           <li>If the bug should be fixed in the current release, the status gets changed to ASSIGNED and a target milestone is set
             appropriately.<sup>2</sup></li>
           <li>If the fix is critical, the target will be the next milestone (like 3.1M3), otherwise it will go into the general 3.1&nbsp;milestone, meaning we intend to address in this release</li>
           <li>If the bug/feature will not be fixed in the current release, it is set to RESOLVED LATER</li>
           <li>Set the priority with these guidelines:
             <ul>
               <li>P1 - stop ship fix, need immediate attention</li>
               <li>P2 - must fix before the release, but can make progress without fix</li>
               <li>P3 - should/would like to fix for the next release</li>
               <li>P4 - would be nice, but not critical, can ship without fixing</li>
             </ul>
           </li>
           <li>The severity tags aren't used much, except to distinguish enhancements from bugs.
             Typically the users specify severities as they see fit.</li>
           <li>The bug will stay as ASSIGNED to the "inbox" account until a developer takes the bug, or
             the team lead assign it to them</li>
         </ul>
       </li>
     </ul>
   </li>
   <li>The developers then work on the bug
     <ul>
       <li>When a developer fixes the bug, the status is set to RESOLVED - FIXED, and it is assigned to another committer on the team to
         verify. It is important that the verifier be a different person than the
         fixer because the fixer is too close to the code and thus may not be as
         diligent at testing the corner cases.</li>
       <li>When a developer commits code, she includes the bug#(s) in the commit
         message.</li>
       <li>It is possible for a bug to be RESOLVED to LATER or WONTFIX or INVALID as well if
         the developer discovers that the fix is too complex/risky or that it is not really a bug</li>
     </ul>
   </li>
   <li>Verify
     <ul>
       <li>All bugs should be verified before the next integration build</li>
       <li>When a committer verifies a fix, the status is changed to VERIFIED</li>
     </ul>
   </li>
   <li>When the project does a major release, the VERIFIED bugs are changed to
     CLOSED.</li>
 </ul>
 <h3>Managing Requirements</h3>
 <p>Projects should be using Bugzilla as part of their requirements process. A
 future version of this document will describe recommended techniques for doing
 so.</p>
 <h3>Writing Good Bug Reports</h3>
 <p>There are many ways to write a good bug report and even more ways to write a
 bad one. The community suggests that these are some of the best bug reports
 submitted to date:</p>
 <ul>
   <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=22122">22122</a> -
     in this bug, not only is the problem accurately described, but a patch is provided to
     <i>our</i> core test suites that tests various permutations of the failure condition.</li>
   <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=76541">76541</a> - feature request with screen
     cast</li>
   <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=95401">95401</a></li>
   <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=97221">97211</a></li>
   <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=113206">113206</a>
     - note the flash movie in comment #5 that illustrates the problem, complete with text overlays and pauses during the movie to illustrate the error condition.</li>
   <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=114496">114496</a></li>
   <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=116682">116682</a>
     - describes the expected behavior and contains a patch</li>
   <li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=117181">117181</a>
     - contains build ID and simple self-contained steps to reproduce the problem in a very short time</li>
 </ul>
 <p>We should all strive to emulate these authors when writing bug reports.</p>
 <p><sup>1</sup> Some projects move bugs that need more information to the
 RESOLVED REMIND state rather than leaving them in the inbox.<br>
 <sup>2</sup> Some projects do not set the target milestone here; instead they
 use a milestone planning meeting to set them all at once.</p>
 <?php
 	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
 ?>
	<?php
	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");

	$pageTitle = "Bugzilla Use";
	$pageKeywords = "development process";
	$pageAuthor = "Bjorn Freeman-Benson Nov 20/05";

	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-after-definitions.php");
	?>
	<div id="maincontent">
	<div id="midcolumn">

	<h1>Bugzilla Use</h1>
	<p><i>version 028 - November 29, 2005</i></p>
	<p><a href="index.php">[This is one page of the larger document.]</a></p>
	<h2>Bugzilla</h2>

	<p>A common question new projects ask is "how should we use Bugzilla
	effectively?". The <a href="http://www.bugzilla.org/docs/2.18/html/using.html">Bugzilla
	documentation</a> describes the basic mechanics and outlines the bug lifecycle
	that is designed into Bugzilla:</p>

	<p align="center"><img border="0" src="images/bzLifecycle.png" width="496" height="579"></p>

	<p>The Eclipse projects have different schemes for using Bugzilla, but a common one
	is as follows:</p>
	<ul>
	<li>Users "own": component, version, platform, OS, severity,
	summary, and description</li>
	<li>The Committers "own": status, resolution, and priority.</li>
	<li>Users may not change the Committer owned fields - this is enforced by
	social convention.</li>
	<li>Bugzilla provides a mechanism to watch another email address and
	developers are expected to use this to watch the component owner's address
	to monitor the incoming bugs for their projects/components.</li>
	<li>At the start of each day, each project/component team lead does bug
	triage. He or she assesses each NEW bug:
	<ul>
	<li>Validation
	<ul>
	<li> verify if the bug is really a bug or if it belongs to this component</li>
	<li>if the bug needs more information to be validated as a bug, add a request for more information/steps to reproduce, etc.
	The bug remains in the NEW state until enough information is received
	to validate it.<sup>1</sup></li>
	<li>if there is no response within a week, close the bug (RESOLVED
	INVALID or WONTFIX) telling the submitter to re-open once they have
	more info</li>
	<li>the bug may get moved to another component/product</li>
	<li>the bug may be a user problem, or may be intended behavior - these
	get annotated with the reason/information and RESOLVED to INVALID or WONTFIX
	or WORKSFORME (generally, INVALID means the report is just bogus,
	WORKSFORME means the report is not a problem, and WONTFIX is used for things
	that are valid requests, but that the team can't do).</li>
	<li>once a bug is validated, it goes to prioritization</li>
	</ul>
	</li>
	<li>Prioritization
	<ul>
	<li>If the bug is a feature request, change the severity to <i> enhancement</i></li>
	<li>If the bug should be fixed in the current release, the status gets changed to ASSIGNED and a target milestone is set
	appropriately.<sup>2</sup></li>
	<li>If the fix is critical, the target will be the next milestone (like 3.1M3), otherwise it will go into the general 3.1 milestone, meaning we intend to address in this release</li>
	<li>If the bug/feature will not be fixed in the current release, it is set to RESOLVED LATER</li>
	<li>Set the priority with these guidelines:
	<ul>
	<li>P1 - stop ship fix, need immediate attention</li>
	<li>P2 - must fix before the release, but can make progress without fix</li>
	<li>P3 - should/would like to fix for the next release</li>
	<li>P4 - would be nice, but not critical, can ship without fixing</li>
	</ul>
	</li>
	<li>The severity tags aren't used much, except to distinguish enhancements from bugs.
	Typically the users specify severities as they see fit.</li>
	<li>The bug will stay as ASSIGNED to the "inbox" account until a developer takes the bug, or
	the team lead assign it to them</li>
	</ul>
	</li>
	</ul>
	</li>
	<li>The developers then work on the bug
	<ul>
	<li>When a developer fixes the bug, the status is set to RESOLVED - FIXED, and it is assigned to another committer on the team to
	verify. It is important that the verifier be a different person than the
	fixer because the fixer is too close to the code and thus may not be as
	diligent at testing the corner cases.</li>
	<li>When a developer commits code, she includes the bug#(s) in the commit
	message.</li>
	<li>It is possible for a bug to be RESOLVED to LATER or WONTFIX or INVALID as well if
	the developer discovers that the fix is too complex/risky or that it is not really a bug</li>
	</ul>
	</li>
	<li>Verify
	<ul>
	<li>All bugs should be verified before the next integration build</li>
	<li>When a committer verifies a fix, the status is changed to VERIFIED</li>
	</ul>
	</li>
	<li>When the project does a major release, the VERIFIED bugs are changed to
	CLOSED.</li>
	</ul>
	<h3>Managing Requirements</h3>
	<p>Projects should be using Bugzilla as part of their requirements process. A
	future version of this document will describe recommended techniques for doing
	so.</p>
	<h3>Writing Good Bug Reports</h3>
	<p>There are many ways to write a good bug report and even more ways to write a
	bad one. The community suggests that these are some of the best bug reports
	submitted to date:</p>
	<ul>
	<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=22122">22122</a> -
	in this bug, not only is the problem accurately described, but a patch is provided to
	<i>our</i> core test suites that tests various permutations of the failure condition.</li>
	<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=76541">76541</a> - feature request with screen
	cast</li>
	<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=95401">95401</a></li>
	<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=97221">97211</a></li>
	<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=113206">113206</a>
	- note the flash movie in comment #5 that illustrates the problem, complete with text overlays and pauses during the movie to illustrate the error condition.</li>
	<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=114496">114496</a></li>
	<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=116682">116682</a>
	- describes the expected behavior and contains a patch</li>
	<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=117181">117181</a>
	- contains build ID and simple self-contained steps to reproduce the problem in a very short time</li>
	</ul>
	<p>We should all strive to emulate these authors when writing bug reports.</p>
	<p><sup>1</sup> Some projects move bugs that need more information to the
	RESOLVED REMIND state rather than leaving them in the inbox.<br>
	<sup>2</sup> Some projects do not set the target milestone here; instead they
	use a milestone planning meeting to set them all at once.</p>
	<?php
	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
	?>