High Resistance mode guidelines originally written by Jesse Glick for NetBeans 3.4. For 3.6, adapted by Jan Chalupa
To fix bugs during high resistance mode requires some special steps.
All developers with any experience are strongly encouraged to subscribe to
There is also NNTP access. Archives
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.
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.
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!).
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.
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.