src/content/community/releases/34/high-resistance.html - netbeans-website-cleanup - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><!-- -*- xhtml -*- -->
 <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
   <title>3.4 High Resistance Mode</title>
   <link rel="stylesheet" type="text/css" href="https://netbeans.org/netbeans.css"/>
   <meta name="TOPIC" content="NB_ORG"/>
   <meta name="TYPE" content="ARTICLE"/>
   <meta name="AUDIENCE" content="NBDEVELOPER"/>
   <meta name="DESCRIPTION" content="Guidelines for NetBeans 3.4 high-resistance bug fixing mode."/>
   <meta name="AUTHOR" content="Jesse Glick"/>
   <meta name="INDEXED" content="Y"/>
  </head>
  <body>

   <h1>3.4 High Resistance Mode</h1>
   <dl>
    <dt><em>Version:</em></dt>
    <dd><!-- hhmts start -->April 24, 2003<!-- hhmts end --></dd>
    <dt><em>Author:</em></dt>
    <dd>Jesse Glick</dd>
   </dl>
   <p>
    We need guidelines for developers and QA for how to control bug fixing during
    the high-resistance stabilization cycle for the <a href="index.html">NetBeans
    3.4 release</a>. This document, based on conversations on
    <code>nbdev@netbeans.org</code> (subjects: <samp>[Proposal] NB 3.4 high
    resistance mode rules</samp> and <samp>Bug Waiver Process for NB 3.4</samp>),
    offers these guidelines.
   </p>
   <p>
    Release coordinators for future releases are encouraged to copy and adapt this
    document for their own releases.
   </p>

   <h2>High Resistance</h2>
   <p>
    To fix bugs during high resistance mode requires some special steps.
   </p>

   <ol>
    <li>
     <p>
      All developers with any experience are strongly encouraged to subscribe to
      <a
      href="mailto:reviewers-subscribe@netbeans.org"><code>reviewers@netbeans.org</code></a>
      immediately. There is also <a
      href="nntp://news.gmane.org/gmane.comp.java.netbeans.reviewers">NNTP access</a>. Archives
      are <a
      href="https://netbeans.org/projects/www/lists/reviewers/archive">here</a>.
     </p>
    </li>
    <li>
     <p>
      After high resistance begins (branch cut) on July 10 2002, all proposed
      patches must be preannounced on <code>reviewers@netbeans.org</code>.
     </p>
     <p>
      Only bug fixes are permitted. All P1 and P2 bugs ought to be fixed unless
      there is a compelling reason not to. P3, P4, and P5 bugs can be fixed if
      they are trivial - safe and uncontroversial.
     </p>
     <p>
      Non-structural (HTML-only) documentation fixes can be made without being
      pre-announced. Minor bundle fixes (spelling errors etc., but not major text
      changes in the GUI) can be made without discussion as well.
     </p>
    </li>
    <li>
     <p>
      The message to this alias should include the issue number (in a hyperlink),
      a subject line summarizing the bug or patch, and a sentence or two
      describing the proposed patch - enough for someone to guess whether he or
      she is interested in the details.
     </p>
     <p>
      The Issuezilla report must be fixed in the trunk; have a full <samp>cvs diff
       -c</samp>/<samp>-u</samp> patch for review (you may link to an already-committed
      patch using CVSweb); full description of the bug and why it is important enough
      to fix; information on testing and safety; etc.
     </p>
     <p>
      The <a
      href="../../guidelines/code-conventions.html">NetBeans
      code conventions</a> are especially important for high-resistance patches.
      In particular, please avoid including gratuitous whitespace-only changes in
      the diff. Other developers will have to read these diff lines and will waste
      time trying to see what you changed!
     </p>
    </li>
    <li>
     <p>
      The developer to whom the issue is assigned, is responsible for getting a
      review from at least one other developer somehow. The other developer should
      add a note to the issue when he/she has reviewed it confirming that the
      patch looks OK.
     </p>
     <p>
      Handy links to help you do good reviews:
      Seamonkey
      Code Reviewer's Guide and <a
      href="http://www.mozilla.org/hacking/reviewers.html">Mozilla
      "super-review"</a>.
     </p>
     <p>
      Objections <em>must</em> be recorded in the Issuezilla bug report,
      <em>not</em> sent back to <code>reviewers@netbeans.org</code> (where even
      the submitter might not see it!).
     </p>
     <p>
      Big arguments can spill over to <code>nbdev@netbeans.org</code> if
      necessary.
     </p>
    </li>
    <li>
     <p>
      If no objections have been raised after 24 hours, and the patch has been
      reviewed, the developer is free to integrate the patch.
     </p>
    </li>
    <li>
     <p>
      A bug fixed only in the trunk should have the target milestone set to
      <code>4.0</code>. If a bug is fixed in the <code>release34</code> branch as
      well, the target milestone should be set to <code>3.4</code>.
     </p>
    </li>
    <li>
     <p>
      After RC1 on July 24 2002, any necessary fixes must be discussed in detail
      on <code>nbdev@netbeans.org</code>. The documentation team can make
      localized, HTML-only docs changes, if they are carefully sanity-checked in
      advance, but must keep <code>nbdev@netbeans.org</code> informed of when
      these changes are planned and committed.
     </p>
    </li>
   </ol>

   <p>
    If you have fixes you do not intend to apply to 3.4, but might be useful in an
    update, you can mark them with the <code>3.4.1_CANDIDATE</code> keyword to
    help track them. Please try to fix such bugs in the trunk as soon as possible.
    If we do in fact make a 3.4.1 release, it will be easy to find what fixes are
    suggested.
   </p>

   <h2>3.4 Waivers</h2>
   <p>
    As a general rule, an honest effort should be made to fix all P1 and P2 bugs
    (<code>DEFECT</code>s) in released modules. After the release candidate,
    however, some bugs may be seen as too dangerous or difficult to fix for the
    3.4 release. In this case you can apply for a waiver:
   </p>

   <ol>
    <li>
     <p>
      Mark the bug report in Issuezilla with the keyword <code>3.4_WAIVER</code>.
     </p>
    </li>
    <li>
     <p>
      Provide a complete justification for the waiver request in the Issuezilla
      description. Some typical justifications:
     </p>
     <ul>
      <li>
       <p>
        The bug fix might have unintentional side-effects worse than the original
        bug; describe why you think this might be so.
       </p>
      </li>
      <li>
       <p>
        Any possible fix would be a significant develoopment effort and you (as
        module owner) just do not have the time to do it; someone else could still
        volunteer however.
       </p>
      </li>
      <li>
       <p>
        The bug is hard or impossible to reproduce and given current information
        you are unable to fix it for this reason, or unable to verify that a
        possible fix really worked. Describe what information or test cases you
        would still like to see.
       </p>
      </li>
     </ul>
    </li>
    <li>
     <p>
      Send a message to <code>reviewers@netbeans.org</code> stating that you are
      requesting a waiver. Include a hyperlink to the issue report for
      convenience.
     </p>
    </li>
    <li>
     <p>
      Reviewers may discuss technicalities by adding Issuezilla comments (and
      adding themselves as CCs if necessary). Serious arguments can spill over
      onto <code>nbdev@netbeans.org</code>.
     </p>
    </li>
    <li>
     <p>
      If no strong objections are received within three days (72 hours) of
      announcing the waiver request, it is considered approved automatically. It
      is not necessary for anyone to explicitly approve they waiver, although
      people may add informational comments that they think it is a good idea to
      waive the bug. If there are serious objections, they must be addressed
      somehow, or the bug reconsidered for fixing.
     </p>
    </li>
    <li>
     <p>
      You may want to post a followup to <code>nbdev@netbeans.org</code> after
      three days reminding people that the issue will not be fixed for 3.4.
     </p>
    </li>
    <li>
     <p>
      Consider marking the issue <code>3.4.1_CANDIDATE</code>, however, if you
      feel it might still be fixable in an update release.
     </p>
    </li>
    <li>
     <p>
      Also consider adding the keyword <code>RELNOTE</code>, CCing the release
      coordinator at a minimum, and writing (in the issue) a summary of the bug
      and any workarounds you would like to see included in the 3.4 release notes.
     </p>
    </li>
   </ol>

   <h2>Unofficial Modules</h2>
   <p>
    Only bugs in modules intended to be released as part of the official 3.4 build
    are automatically affected by high-resistance commit rules. However, if you
    have a module which you would like to release in stable form for 3.4, you (the
    module owner) are responsible for creating a <code>release34</code> branch in
    your module's sources.
   </p>
   <p>
    You should then follow the high-resistance process as usual. However, the
    cutoff date is yours to determine: when you are satisfied that all important
    fixes have been made, and there is some independent assurance (e.g. from
    Quality Assurance engineers) that your module is stable and usable, you can
    push it on the Auto Update server - possibly after the main 3.4 release has
    been published.
   </p>
   <p>
    Waivers are not necessary for bugs not in the standard distribution of 3.4. As
    module owner you must decide when, if ever, the module is stable enough to be
    released on Auto Update.
   </p>

  </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><!-- -- xhtml -- -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<title>3.4 High Resistance Mode</title>
	<link rel="stylesheet" type="text/css" href="https://netbeans.org/netbeans.css"/>
	<meta name="TOPIC" content="NB_ORG"/>
	<meta name="TYPE" content="ARTICLE"/>
	<meta name="AUDIENCE" content="NBDEVELOPER"/>
	<meta name="DESCRIPTION" content="Guidelines for NetBeans 3.4 high-resistance bug fixing mode."/>
	<meta name="AUTHOR" content="Jesse Glick"/>
	<meta name="INDEXED" content="Y"/>
	</head>
	<body>

	<h1>3.4 High Resistance Mode</h1>
	<dl>
	<dt><em>Version:</em></dt>
	<dd><!-- hhmts start -->April 24, 2003<!-- hhmts end --></dd>
	<dt><em>Author:</em></dt>
	<dd>Jesse Glick</dd>
	</dl>
	<p>
	We need guidelines for developers and QA for how to control bug fixing during
	the high-resistance stabilization cycle for the <a href="index.html">NetBeans
	3.4 release</a>. This document, based on conversations on
	<code>nbdev@netbeans.org</code> (subjects: <samp>[Proposal] NB 3.4 high
	resistance mode rules</samp> and <samp>Bug Waiver Process for NB 3.4</samp>),
	offers these guidelines.
	</p>
	<p>
	Release coordinators for future releases are encouraged to copy and adapt this
	document for their own releases.
	</p>

	<h2>High Resistance</h2>
	<p>
	To fix bugs during high resistance mode requires some special steps.
	</p>

	<ol>
	<li>
	<p>
	All developers with any experience are strongly encouraged to subscribe to
	<a
	href="mailto:reviewers-subscribe@netbeans.org"><code>reviewers@netbeans.org</code></a>
	immediately. There is also <a
	href="nntp://news.gmane.org/gmane.comp.java.netbeans.reviewers">NNTP access</a>. Archives
	are <a
	href="https://netbeans.org/projects/www/lists/reviewers/archive">here</a>.
	</p>
	</li>
	<li>
	<p>
	After high resistance begins (branch cut) on July 10 2002, all proposed
	patches must be preannounced on <code>reviewers@netbeans.org</code>.
	</p>
	<p>
	Only bug fixes are permitted. All P1 and P2 bugs ought to be fixed unless
	there is a compelling reason not to. P3, P4, and P5 bugs can be fixed if
	they are trivial - safe and uncontroversial.
	</p>
	<p>
	Non-structural (HTML-only) documentation fixes can be made without being
	pre-announced. Minor bundle fixes (spelling errors etc., but not major text
	changes in the GUI) can be made without discussion as well.
	</p>
	</li>
	<li>
	<p>
	The message to this alias should include the issue number (in a hyperlink),
	a subject line summarizing the bug or patch, and a sentence or two
	describing the proposed patch - enough for someone to guess whether he or
	she is interested in the details.
	</p>
	<p>
	The Issuezilla report must be fixed in the trunk; have a full <samp>cvs diff
	-c</samp>/<samp>-u</samp> patch for review (you may link to an already-committed
	patch using CVSweb); full description of the bug and why it is important enough
	to fix; information on testing and safety; etc.
	</p>
	<p>
	The <a
	href="../../guidelines/code-conventions.html">NetBeans
	code conventions</a> are especially important for high-resistance patches.
	In particular, please avoid including gratuitous whitespace-only changes in
	the diff. Other developers will have to read these diff lines and will waste
	time trying to see what you changed!
	</p>
	</li>
	<li>
	<p>
	The developer to whom the issue is assigned, is responsible for getting a
	review from at least one other developer somehow. The other developer should
	add a note to the issue when he/she has reviewed it confirming that the
	patch looks OK.
	</p>
	<p>
	Handy links to help you do good reviews:
	Seamonkey
	Code Reviewer's Guide and <a
	href="http://www.mozilla.org/hacking/reviewers.html">Mozilla
	"super-review"</a>.
	</p>
	<p>
	Objections <em>must</em> be recorded in the Issuezilla bug report,
	<em>not</em> sent back to <code>reviewers@netbeans.org</code> (where even
	the submitter might not see it!).
	</p>
	<p>
	Big arguments can spill over to <code>nbdev@netbeans.org</code> if
	necessary.
	</p>
	</li>
	<li>
	<p>
	If no objections have been raised after 24 hours, and the patch has been
	reviewed, the developer is free to integrate the patch.
	</p>
	</li>
	<li>
	<p>
	A bug fixed only in the trunk should have the target milestone set to
	<code>4.0</code>. If a bug is fixed in the <code>release34</code> branch as
	well, the target milestone should be set to <code>3.4</code>.
	</p>
	</li>
	<li>
	<p>
	After RC1 on July 24 2002, any necessary fixes must be discussed in detail
	on <code>nbdev@netbeans.org</code>. The documentation team can make
	localized, HTML-only docs changes, if they are carefully sanity-checked in
	advance, but must keep <code>nbdev@netbeans.org</code> informed of when
	these changes are planned and committed.
	</p>
	</li>
	</ol>

	<p>
	If you have fixes you do not intend to apply to 3.4, but might be useful in an
	update, you can mark them with the <code>3.4.1_CANDIDATE</code> keyword to
	help track them. Please try to fix such bugs in the trunk as soon as possible.
	If we do in fact make a 3.4.1 release, it will be easy to find what fixes are
	suggested.
	</p>

	<h2>3.4 Waivers</h2>
	<p>
	As a general rule, an honest effort should be made to fix all P1 and P2 bugs
	(<code>DEFECT</code>s) in released modules. After the release candidate,
	however, some bugs may be seen as too dangerous or difficult to fix for the
	3.4 release. In this case you can apply for a waiver:
	</p>

	<ol>
	<li>
	<p>
	Mark the bug report in Issuezilla with the keyword <code>3.4_WAIVER</code>.
	</p>
	</li>
	<li>
	<p>
	Provide a complete justification for the waiver request in the Issuezilla
	description. Some typical justifications:
	</p>
	<ul>
	<li>
	<p>
	The bug fix might have unintentional side-effects worse than the original
	bug; describe why you think this might be so.
	</p>
	</li>
	<li>
	<p>
	Any possible fix would be a significant develoopment effort and you (as
	module owner) just do not have the time to do it; someone else could still
	volunteer however.
	</p>
	</li>
	<li>
	<p>
	The bug is hard or impossible to reproduce and given current information
	you are unable to fix it for this reason, or unable to verify that a
	possible fix really worked. Describe what information or test cases you
	would still like to see.
	</p>
	</li>
	</ul>
	</li>
	<li>
	<p>
	Send a message to <code>reviewers@netbeans.org</code> stating that you are
	requesting a waiver. Include a hyperlink to the issue report for
	convenience.
	</p>
	</li>
	<li>
	<p>
	Reviewers may discuss technicalities by adding Issuezilla comments (and
	adding themselves as CCs if necessary). Serious arguments can spill over
	onto <code>nbdev@netbeans.org</code>.
	</p>
	</li>
	<li>
	<p>
	If no strong objections are received within three days (72 hours) of
	announcing the waiver request, it is considered approved automatically. It
	is not necessary for anyone to explicitly approve they waiver, although
	people may add informational comments that they think it is a good idea to
	waive the bug. If there are serious objections, they must be addressed
	somehow, or the bug reconsidered for fixing.
	</p>
	</li>
	<li>
	<p>
	You may want to post a followup to <code>nbdev@netbeans.org</code> after
	three days reminding people that the issue will not be fixed for 3.4.
	</p>
	</li>
	<li>
	<p>
	Consider marking the issue <code>3.4.1_CANDIDATE</code>, however, if you
	feel it might still be fixable in an update release.
	</p>
	</li>
	<li>
	<p>
	Also consider adding the keyword <code>RELNOTE</code>, CCing the release
	coordinator at a minimum, and writing (in the issue) a summary of the bug
	and any workarounds you would like to see included in the 3.4 release notes.
	</p>
	</li>
	</ol>

	<h2>Unofficial Modules</h2>
	<p>
	Only bugs in modules intended to be released as part of the official 3.4 build
	are automatically affected by high-resistance commit rules. However, if you
	have a module which you would like to release in stable form for 3.4, you (the
	module owner) are responsible for creating a <code>release34</code> branch in
	your module's sources.
	</p>
	<p>
	You should then follow the high-resistance process as usual. However, the
	cutoff date is yours to determine: when you are satisfied that all important
	fixes have been made, and there is some independent assurance (e.g. from
	Quality Assurance engineers) that your module is stable and usable, you can
	push it on the Auto Update server - possibly after the main 3.4 release has
	been published.
	</p>
	<p>
	Waivers are not necessary for bugs not in the standard distribution of 3.4. As
	module owner you must decide when, if ever, the module is stable enough to be
	released on Auto Update.
	</p>

	</body>
	</html>