Jesse Glick, Jan Chalupa, Trung Duc Tran, Jiri Kovalsky
High Resistance
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
are here.
After high resistance begins on September 13, 2006, 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 release55_dev branch; 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 55_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 in the release55_dev branch,
the developer is free to integrate the patch.
A bug fixed only in the trunk should have the target milestone set to
dev. If a bug is fixed in the release55 branch as
well, the target milestone should be set to 5.5.
All P3 bug reports must be evaluated promptly to make sure there are no P1,
P2 bugs hidden among them. P3 bugs will not be fixed in
release55 branch. If a P3 bug is considered important enough, then
its priority must be adjusted accordingly, ie raised to P2 or P1 before the
fix can get into release55 branch.
Note: For NetBeans 5.5, only Web Apps and J2EE support are being actively
developed. P2 bugs in non-J2EE areas must be evaluated, but are not required to be
fixed unless considered showstoppers for the release.