development/bug_process.php - www.eclipse.org/mtj - Git at Google

 <?php  																														require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); 	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); 	$App 	= new App();	$Nav	= new Nav();	$Menu 	= new Menu();		include($App->getProjectCommon());    # All on the same line to unclutter the user's desktop'

 /* Begin: page-specific settings. */
 $pageTitle 		= "DSDP&nbsp; - &nbsp;Mobile Tools for Java &nbsp; (MTJ) &nbsp; Bug Process";
 $pageKeywords	= "DSDP, mtj, Bugs, Process, Guidelines";
 $pageAuthor		= "Diego Madruga Sandin";

 /* Required eclipse basic classes */
 require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");
 /* Functions and modules related to Navbar objects */
 require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php");
 /* Functions and modules related to the page top eclipse menu */
 require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php");

 $App 	= new App();
 /* Left Navbar */
 $Nav	= new Nav();
 /*  Page top eclipse menu */
 $Menu 	= new Menu();

 /* Find the _projectCommon.php file and include it */
 include($App->getProjectCommon());

 /* Page content */
 $html = <<<EOHTML

 	<div id="midcolumn">

 		<h1>$pageTitle</h1>
 		<p>This documents how the Mobile Tools for Java<sup><small>TM</small></sup> (MTJ) Project uses
 		<a href="http://bugs.eclipse.org/bugs">Bugzilla</a> to handle
 		bug reports, enhancement requests, patches etc. It covers
 		basic lifecycle information and clarifications for how to
 		use the various Bugzilla fields.</p>

 		<h2>Bug Lifecycle</h2>
 		<p>Everybody - users and developers - may apply for a
 		<a href="http://bugs.eclipse.org/bugs">Bugzilla account</a>
 		and submit bug reports or enhancement requests.</p>
 		<ul>
 		  <li><a target="_top" href="https://bugs.eclipse.org/bugs/enter_bug.cgi?assigned_to=dsdp.mtj-inbox%40eclipse.org&blocked=&bug_file_loc=http%3A%2F%2F&bug_severity=normal&bug_status=NEW&comment=Overview%3A%20(More%20detailed%20restatement%20of%20summary)%0D%0A%0D%0ASteps%20to%20Reproduce%3A%20(Minimized%2C%20easy-to-follow%20steps%20that%20will%20trigger%20the%20bug)%0D%0A%0D%0A%20%20%20%201)%0D%0A%20%20%20%202)%0D%0A%0D%0AActual%20Results%3A%20(What%20MTJ%20did%20after%20performing%20the%20above%20steps)%0D%0A%0D%0A%0D%0A%0D%0AExpected%20Results%3A%20(What%20MTJ%20should%20have%20done%2C%20were%20the%20bug%20not%20present)%0D%0A%0D%0A%0D%0A%0D%0ABuild%20Date%20%26%20Platform%3A%20(update%20with%20the%20correct%20values%20from%20your%20workspace)%0D%0A%20%0D%0A%20Installation%20%3A%20eclipse-SDK-3.4.0%20(I20080617-2000)%20%0D%0A%20MTJ%20install%20%20%3A%20Runtime%20|%20SDK%20|%20Examples%0D%0A%20java.runtime%20%3A%20Java(TM)%20SE%20Runtime%20Environment%20(build%201.6.0_07-b06)%0D%0A%20os.name%3A%20%20%20%20%20%3A%20Windows%20XP%20Professional%2C%20Service%20Pack%203%0D%0A%0D%0AAdditional%20Builds%20and%20Platforms%3A%20(Whether%20or%20not%20it%20occurs%20on%20other%20platforms)%0D%0A%0D%0A%0D%0A%0D%0AAdditional%20Information%3A%20(Any%20other%20useful%20information)%0D%0A%0D%0A%0D%0A&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&dependson=&description=&flag_type-1=X&flag_type-2=X&flag_type-4=X&flag_type-6=X&flag_type-7=X&flag_type-8=X&form_name=enter_bug&keywords=&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=All&priority=P3&product=MTJ&qa_contact=&rep_platform=All&short_desc=&version=unspecified">Submit a new bug</a></li>
 		  <li><a target="_top" href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=mtj&version=unspecified&rep_platform=All&op_sys=All&priority=P3&bug_severity=enhancement&form_name=enter_bug">Request an enhancement</a></li>
 		</ul>
 		<p>
     		Once the bug report is filed, contributors and committers
     		work on it, including updates to bug status. All users
     		may contribute to the discussion by adding comments (but
     		typically not change the status fields).
     		The Eclipse Process Guidelines contain some good
     		<a href="http://www.eclipse.org/projects/dev_process/bugzilla-use.php">
     		information	and a handy diagram</a> for understanding the
     		lifecycle of an issue in Bugzilla.
 		<p/>

 		<h3>How to defer bugs</h2>
         <p>
             The main goal of these guidelines is to be able and write good bugzilla queries
             that allow us avoid looking at deferred bugs again later. So here is the process:
             <ul>
                 <li>
                     Set the <b>Priority</b> according to personal judgement of importance:
                     Even bugs with a high priority can be deferred to an upcoming release
                     if time just dont permit fixing them.
                 </li>
                 <li>
                 	Set Resolved, Resolution=<b>INVALID</b> for requests that do not make sense.
                 </li>
                 <li>
                     Set Resolved, Resolution=<b>WONTFIX</b> for bugs that we will supposedly
                     never address e.g. because there is a suitable workaround or the effort is
                     just too high although the request makes sense.
                 </li>
                 <li>
                     Set <b>Target Milestone=Future</b> for bugs that make sense but are
                     too much effort for the current release. They should be triaged again for
                     the next release, and perhaps be documented as known limitations in
                     the release notes. Such bugs will typically be in NEW state and assigned
                     to <b>dsdp.mtj-inbox@eclipse.org</b>
                 </li>
                 <li>
                     <b>Assign</b> the bug to a developer and set the <b>target milestone</b>
                     for bugs that we want to address in the current release cycle.
                 </li>
                 <li>
                     Assign bugs to the <b>dsdp.mtj-inbox@eclipse.org</b> with
                     the default target milestone="---" if you have no idea what to do with
                     a request and also dont know who else could handle it. It will triaged
                     again by all committers together in the next committer meeting. Please
                     do this as a last resort, though, since looking multiple times at the
                     same bug is unnecessary effort; and add a comment with your thoughts
                     on the bug.
                 </li>
             </ul>
         </p>

 		<h3>How to verify and close</h3>
 		<ul>
 		  <li>Bugs that are set RESOLVED are candidates for verification.</li>
 		  <li>Ideally, the person who filed a bug should also verify it and set
 		     it to <b>VERIFIED</b> if OK.</li>
 		  <li>During the final release test cycle, all RESOLVED and even VERIFIED
 		     bugs will be checked again. If they pass the test, they will be set
 		     <b>CLOSED</b>.</li>
 		  <li>Enhancement requests and applied patches can also be set <b>CLOSED</b>
 		     right after checkin, especially if they do not apply to testable
 		     product functionality but rather some code cleanliness.</li>
 		</ul>
 		<h2>Clarification of Fields</h2>
 		<ul>
 		  <li><b>Platform</b> and <b>OS</b>: These should be set by the submitter
 		     of a bug to describe the platform and OS on which a bug was detected.
 		     This does not mean that the bug would occur only on this particular
 		     platform.
 		     <ul>
 		       <li>Use Platform <b>All</b> only if you have good evidence that a
 		           bug actually occurs on all platforms.</li>
 		       <li>When you are sure that a bug occurs <b>only</b> on a particular
 		           platform, please indicate so in the <b>Summary</b> field by adding
 		           a tag lice [mac] or [linux]</li>
 		     </ul></li>
 		</ul><p/>


 		<h2>Submitting a Patch</h2>
 		Every user may submit a patch for an issue he finds, by attaching
 		the code to the corresponding Bugzilla item. Submitting patches turns
 		the ordinary user into a contributor, for which he or she will be
 		given credit to.<br/>
 		Please attach only patches on bugzilla for which you have the right
 		to attach them. In the typical case, if you put a legal notice like
 		the following alongside your contribution, it will speed up the
 		contribution process:
 		    <p style="border: thin 1px dashed; background-color: ivory;
                 padding-top: 2px;
                 padding-left: 2px;
                 padding-right: 2px;
                 padding-bottom: 2px">
 		    Legal Message: I, {name}, declare that I developed attached code from
 			scratch, without referencing any 3rd party materials except material
 			licensed under the EPL. {I am authorized by my employer to make this
 			contribution under the EPL.}
 		    </p>
 		If this message does not apply for you (e.g. because you did use 3rd party
 		materials), please contact the <a href="mailto:dsdp-mtj-dev@eclipse.org">
 		dsdp-mtj-dev@eclipse.org</a> Developer Mailing List to seek assistance of
 		a committer.<br/>
 		Once your contribution is attached to Bugzilla, a committer will pick it
 		up and follow the committer guidelines to merge your contribution.
 		<p/>

 		<h2>Best Practices</h2>
 		<ul>
 		  	<li>Before reporting a bug, please read the <a href="https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html">bug writing</a> guidelines.</li>
 		</ul>

 		<h2>Watch the dsdp.mtj-inbox@eclipse.org user for new bugs</h2>
 		<p> You need to use the Bugzilla "watch user" feature to receive notifications
 		from this list. Below are the steps to configure your Bugzilla account properly:</p>
         <ol>
         <li>Login to Bugzilla and select the "<a href="https://bugs.eclipse.org/bugs/userprefs.cgi">preferences</a>" link.</li>
         <li>Once there click the "<a href="https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email">email preferences</a>" tab.</li>
         <li>Put <b>dsdp.mtj-inbox@eclipse.org</b> in the "Add users to my watch list" text
         box at the bottom and click the submit button.</li>
         </ol>
         <p>The user <b>dsdp.mtj-inbox@eclipse.org</b> was set as the default
         contact for all components/products from the MTJ and anytime someone
         posts a bug against those we will be notified.</p>
 	</div>
 <p/>
 EOHTML;

 # Generate the web page
 $App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
 ?>
	<?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop'

	/* Begin: page-specific settings. */
	$pageTitle = "DSDP  -  Mobile Tools for Java   (MTJ)   Bug Process";
	$pageKeywords = "DSDP, mtj, Bugs, Process, Guidelines";
	$pageAuthor = "Diego Madruga Sandin";

	/* Required eclipse basic classes */
	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");
	/* Functions and modules related to Navbar objects */
	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php");
	/* Functions and modules related to the page top eclipse menu */
	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php");

	$App = new App();
	/* Left Navbar */
	$Nav = new Nav();
	/* Page top eclipse menu */
	$Menu = new Menu();

	/* Find the _projectCommon.php file and include it */
	include($App->getProjectCommon());

	/* Page content */
	$html = <<<EOHTML

	<div id="midcolumn">

	<h1>$pageTitle</h1>
	<p>This documents how the Mobile Tools for Java<sup><small>TM</small></sup> (MTJ) Project uses
	<a href="http://bugs.eclipse.org/bugs">Bugzilla</a> to handle
	bug reports, enhancement requests, patches etc. It covers
	basic lifecycle information and clarifications for how to
	use the various Bugzilla fields.</p>

	<h2>Bug Lifecycle</h2>
	<p>Everybody - users and developers - may apply for a
	<a href="http://bugs.eclipse.org/bugs">Bugzilla account</a>
	and submit bug reports or enhancement requests.</p>
	<ul>
	<li><a target="_top" href="https://bugs.eclipse.org/bugs/enter_bug.cgi?assigned_to=dsdp.mtj-inbox%40eclipse.org&blocked=&bug_file_loc=http%3A%2F%2F&bug_severity=normal&bug_status=NEW&comment=Overview%3A%20(More%20detailed%20restatement%20of%20summary)%0D%0A%0D%0ASteps%20to%20Reproduce%3A%20(Minimized%2C%20easy-to-follow%20steps%20that%20will%20trigger%20the%20bug)%0D%0A%0D%0A%20%20%20%201)%0D%0A%20%20%20%202)%0D%0A%0D%0AActual%20Results%3A%20(What%20MTJ%20did%20after%20performing%20the%20above%20steps)%0D%0A%0D%0A%0D%0A%0D%0AExpected%20Results%3A%20(What%20MTJ%20should%20have%20done%2C%20were%20the%20bug%20not%20present)%0D%0A%0D%0A%0D%0A%0D%0ABuild%20Date%20%26%20Platform%3A%20(update%20with%20the%20correct%20values%20from%20your%20workspace)%0D%0A%20%0D%0A%20Installation%20%3A%20eclipse-SDK-3.4.0%20(I20080617-2000)%20%0D%0A%20MTJ%20install%20%20%3A%20Runtime%20\|%20SDK%20\|%20Examples%0D%0A%20java.runtime%20%3A%20Java(TM)%20SE%20Runtime%20Environment%20(build%201.6.0_07-b06)%0D%0A%20os.name%3A%20%20%20%20%20%3A%20Windows%20XP%20Professional%2C%20Service%20Pack%203%0D%0A%0D%0AAdditional%20Builds%20and%20Platforms%3A%20(Whether%20or%20not%20it%20occurs%20on%20other%20platforms)%0D%0A%0D%0A%0D%0A%0D%0AAdditional%20Information%3A%20(Any%20other%20useful%20information)%0D%0A%0D%0A%0D%0A&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&dependson=&description=&flag_type-1=X&flag_type-2=X&flag_type-4=X&flag_type-6=X&flag_type-7=X&flag_type-8=X&form_name=enter_bug&keywords=&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=All&priority=P3&product=MTJ&qa_contact=&rep_platform=All&short_desc=&version=unspecified">Submit a new bug</a></li>
	<li><a target="_top" href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=mtj&version=unspecified&rep_platform=All&op_sys=All&priority=P3&bug_severity=enhancement&form_name=enter_bug">Request an enhancement</a></li>
	</ul>
	<p>
	Once the bug report is filed, contributors and committers
	work on it, including updates to bug status. All users
	may contribute to the discussion by adding comments (but
	typically not change the status fields).
	The Eclipse Process Guidelines contain some good
	<a href="http://www.eclipse.org/projects/dev_process/bugzilla-use.php">
	information and a handy diagram</a> for understanding the
	lifecycle of an issue in Bugzilla.
	<p/>

	<h3>How to defer bugs</h2>
	<p>
	The main goal of these guidelines is to be able and write good bugzilla queries
	that allow us avoid looking at deferred bugs again later. So here is the process:
	<ul>
	<li>
	Set the <b>Priority</b> according to personal judgement of importance:
	Even bugs with a high priority can be deferred to an upcoming release
	if time just dont permit fixing them.
	</li>
	<li>
	Set Resolved, Resolution=<b>INVALID</b> for requests that do not make sense.
	</li>
	<li>
	Set Resolved, Resolution=<b>WONTFIX</b> for bugs that we will supposedly
	never address e.g. because there is a suitable workaround or the effort is
	just too high although the request makes sense.
	</li>
	<li>
	Set <b>Target Milestone=Future</b> for bugs that make sense but are
	too much effort for the current release. They should be triaged again for
	the next release, and perhaps be documented as known limitations in
	the release notes. Such bugs will typically be in NEW state and assigned
	to <b>dsdp.mtj-inbox@eclipse.org</b>
	</li>
	<li>
	<b>Assign</b> the bug to a developer and set the <b>target milestone</b>
	for bugs that we want to address in the current release cycle.
	</li>
	<li>
	Assign bugs to the <b>dsdp.mtj-inbox@eclipse.org</b> with
	the default target milestone="---" if you have no idea what to do with
	a request and also dont know who else could handle it. It will triaged
	again by all committers together in the next committer meeting. Please
	do this as a last resort, though, since looking multiple times at the
	same bug is unnecessary effort; and add a comment with your thoughts
	on the bug.
	</li>
	</ul>
	</p>

	<h3>How to verify and close</h3>
	<ul>
	<li>Bugs that are set RESOLVED are candidates for verification.</li>
	<li>Ideally, the person who filed a bug should also verify it and set
	it to <b>VERIFIED</b> if OK.</li>
	<li>During the final release test cycle, all RESOLVED and even VERIFIED
	bugs will be checked again. If they pass the test, they will be set
	<b>CLOSED</b>.</li>
	<li>Enhancement requests and applied patches can also be set <b>CLOSED</b>
	right after checkin, especially if they do not apply to testable
	product functionality but rather some code cleanliness.</li>
	</ul>
	<h2>Clarification of Fields</h2>
	<ul>
	<li><b>Platform</b> and <b>OS</b>: These should be set by the submitter
	of a bug to describe the platform and OS on which a bug was detected.
	This does not mean that the bug would occur only on this particular
	platform.
	<ul>
	<li>Use Platform <b>All</b> only if you have good evidence that a
	bug actually occurs on all platforms.</li>
	<li>When you are sure that a bug occurs <b>only</b> on a particular
	platform, please indicate so in the <b>Summary</b> field by adding
	a tag lice [mac] or [linux]</li>
	</ul></li>
	</ul><p/>


	<h2>Submitting a Patch</h2>
	Every user may submit a patch for an issue he finds, by attaching
	the code to the corresponding Bugzilla item. Submitting patches turns
	the ordinary user into a contributor, for which he or she will be
	given credit to.<br/>
	Please attach only patches on bugzilla for which you have the right
	to attach them. In the typical case, if you put a legal notice like
	the following alongside your contribution, it will speed up the
	contribution process:
	<p style="border: thin 1px dashed; background-color: ivory;
	padding-top: 2px;
	padding-left: 2px;
	padding-right: 2px;
	padding-bottom: 2px">
	Legal Message: I, {name}, declare that I developed attached code from
	scratch, without referencing any 3rd party materials except material
	licensed under the EPL. {I am authorized by my employer to make this
	contribution under the EPL.}
	</p>
	If this message does not apply for you (e.g. because you did use 3rd party
	materials), please contact the <a href="mailto:dsdp-mtj-dev@eclipse.org">
	dsdp-mtj-dev@eclipse.org</a> Developer Mailing List to seek assistance of
	a committer.<br/>
	Once your contribution is attached to Bugzilla, a committer will pick it
	up and follow the committer guidelines to merge your contribution.
	<p/>

	<h2>Best Practices</h2>
	<ul>
	<li>Before reporting a bug, please read the <a href="https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html">bug writing</a> guidelines.</li>
	</ul>

	<h2>Watch the dsdp.mtj-inbox@eclipse.org user for new bugs</h2>
	<p> You need to use the Bugzilla "watch user" feature to receive notifications
	from this list. Below are the steps to configure your Bugzilla account properly:</p>
	<ol>
	<li>Login to Bugzilla and select the "<a href="https://bugs.eclipse.org/bugs/userprefs.cgi">preferences</a>" link.</li>
	<li>Once there click the "<a href="https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email">email preferences</a>" tab.</li>
	<li>Put <b>dsdp.mtj-inbox@eclipse.org</b> in the "Add users to my watch list" text
	box at the bottom and click the submit button.</li>
	</ol>
	<p>The user <b>dsdp.mtj-inbox@eclipse.org</b> was set as the default
	contact for all components/products from the MTJ and anytime someone
	posts a bug against those we will be notified.</p>
	</div>
	<p/>
	EOHTML;

	# Generate the web page
	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
	?>