We need guidelines for developers and QA for how to control bug fixing during
the high-resistance stabilization cycle for the NetBeans
3.4 release. This document, based on conversations on
(subjects: [Proposal] NB 3.4 high
resistance mode rules and Bug Waiver Process for NB 3.4),
offers these guidelines.
Release coordinators for future releases are encouraged to copy and adapt this
document for their own releases.
To fix bugs during high resistance mode requires some special steps.
All developers with any experience are strongly encouraged to subscribe to
immediately. There is also NNTP access. Archives
After high resistance begins (branch cut) on July 10 2002, all proposed
patches must be preannounced on .
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.
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.
code conventions 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!
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!).
Big arguments can spill over to if
If no objections have been raised after 24 hours, and the patch has been
reviewed, the developer is free to integrate the patch.
A bug fixed only in the trunk should have the target milestone set to
4.0. If a bug is fixed in the release34 branch as
well, the target milestone should be set to 3.4.
After RC1 on July 24 2002, any necessary fixes must be discussed in detail
on . The documentation team can make
localized, HTML-only docs changes, if they are carefully sanity-checked in
advance, but must keep informed of when
these changes are planned and committed.
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 3.4.1_CANDIDATE 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
As a general rule, an honest effort should be made to fix all P1 and P2 bugs
(DEFECTs) 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:
Mark the bug report in Issuezilla with the keyword 3.4_WAIVER.
Provide a complete justification for the waiver request in the Issuezilla
description. Some typical justifications:
The bug fix might have unintentional side-effects worse than the original
bug; describe why you think this might be so.
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
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.
Send a message to stating that you are
requesting a waiver. Include a hyperlink to the issue report for
Reviewers may discuss technicalities by adding Issuezilla comments (and
adding themselves as CCs if necessary). Serious arguments can spill over
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.
You may want to post a followup to after
three days reminding people that the issue will not be fixed for 3.4.
Consider marking the issue 3.4.1_CANDIDATE, however, if you
feel it might still be fixable in an update release.
Also consider adding the keyword RELNOTE, 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.
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 release34 branch in
your module's sources.
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
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.