3.4 High Resistance Mode

April 24, 2003
Jesse Glick

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.

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 immediately. There is also NNTP access. Archives are here.

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

  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 NetBeans 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!

  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.

    Handy links to help you do good reviews: Seamonkey Code Reviewer's Guide and Mozilla "super-review".

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

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

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

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

3.4 Waivers

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:

  1. Mark the bug report in Issuezilla with the keyword 3.4_WAIVER.

  2. 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 volunteer however.

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

  3. Send a message to stating that you are requesting a waiver. Include a hyperlink to the issue report for convenience.

  4. Reviewers may discuss technicalities by adding Issuezilla comments (and adding themselves as CCs if necessary). Serious arguments can spill over onto .

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

  6. You may want to post a followup to after three days reminding people that the issue will not be fixed for 3.4.

  7. Consider marking the issue 3.4.1_CANDIDATE, however, if you feel it might still be fixable in an update release.

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

Unofficial Modules

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 been published.

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.

Not logged in. Log in, Register