3.6 High Resistance Mode

March 1, 2004
Jesse Glick, Jan Chalupa

High Resistance mode guidelines originally written by Jesse Glick for NetBeans 3.4. For 3.6, adapted by Jan Chalupa

High Resistance

To fix bugs during high resistance mode requires some special steps.

  1. All developers with any experience are strongly encouraged to subscribe to There is also NNTP access. Archives are here.

  2. After high resistance begins on March 1 2004, all proposed patches must be preannounced on .

    Only high priority bug fixes are permitted. All P1 and P2 bugs ought to be fixed unless there is a compelling reason not to.

    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.

  3. 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.

    The Issuezilla report must be fixed in the trunk; have a full cvs diff -c/-u 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.

    The issue must be marked with the 36_HR_FIX keyword.

  4. 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.

    Objections must be recorded in the Issuezilla bug report, not sent back to (where even the submitter might not see it!).

  5. If no objections have been raised after 24 hours, and the patch has been reviewed by another developer and verified by QA, the developer is free to integrate the patch.

  6. A bug fixed only in the trunk should have the target milestone set to promo-D. If a bug is fixed in the release36 branch as well, the target milestone should be set to 3.6.

Fixes not intended to be applied to 3.6, but potentially useful in an update, can be marked with the 3.6.1_CANDIDATE keyword to help track them. In case a 3.6.1 release is ever made, it will be easy to find what fixes are suggested.

Not logged in. Log in, Register