GlassFish Server Open Source Edition 3.1

Change Control Process for High Resistance Mode

(v1.3)

Overview

It is important to control the rate of change in a project as the project approaches completion. It is a fact for most software projects that a small percentage of "bug fixes" introduce new bugs and therefore it is necessary to enact a formal process to manage what comes into a project in its final stage before release.

This document describes the change control process the GlassFish project will use.

See "Why we all sell code with bugs" for a good article on how to prioritize which bugs should be fixed in a software project.

Should I fix this issue now?

There usually is no easy answer to this question given the varying factors that must be considered. Clearly not every bug needs to be fixed and many bug fixes can be deferred to future releases. It is important that we use consistent and objective criteria across the project to determine if the issue should be fixed now, later or never.

The following types of issues are good candidates to be fixed prior to release:

• Impacts product security
• Represents a CTS failure
• Is a regression of functionality or performance available in a prior release
• Introduces an incompatibility
• Likely to generate a customer support call
• Significantly impacts the operation of a primary release driver feature
• An in-your-face issue that will touch the majority of users

Meeting the above criteria is not sufficient to give a bug fix a green light for integration. The answers to the following questions must be understood and taken into account:

1. How bad is its impact? (Severity)

• Identify why the fix needs to occur now:
  • Impacts product security
  • Represents a CTS failure
  • Is a regression of functionality or performance available in a prior release
  • Introduces an incompatibility
  • Likely to generate a customer support call
  • Significantly impacts the operation of a primary release driver feature
  • An in-your-face issue that will touch the majority of users

2. How often does it happen? (Frequency)
3. How much effort is required to fix it? (Cost)
4. What is the risk of fixing it? (Risk)
5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
7. How long has the bug existed in the product?
8. Do regression tests exist for this issue?
9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
10. When will a tested fix be ready for integration?

The first two questions are directly related to the criteria above while the second two questions address the trade-offs of fixing a bug. Can we afford to do it? Is the risk worth the effort? If the first two questions suggest there is no urgency to fix the issue then there probably is not a need to fix the issue in the current release timeframe.

Bugs with big impact, high frequency, low effort to fix and low risk should be high priority to fix now while bugs with little impact or frequency and high cost/risk to fix should be deferred (or even closed as will-not-fix).

Change Control Process

The following process will be used by developers to request approval to work on a bug fix:

Stage 1 (Approval to develop the bug fix)

1. Add the "3_1-review" tag to the issue
2. Add detailed answers to the questions below as well as any supporting information as a note in the issue:

How bad is its impact? (Severity)
  Identify why the fix needs to occur now:
    * Impacts product security
    * Represents a CTS failure
    * Is a regression of functionality or performance available in a prior release
    * Introduces an incompatibility
    * Likely to generate a customer support call
    * Significantly impacts the operation of a primary release driver feature
    * An in-your-face issue that will touch the majority of users

How often does it happen? (Frequency)

How much effort is required to fix it? (Cost)

What is the risk of fixing it? (Risk)

Does a work around for the issue exist?   Can the workaround be reasonably employed by the end user?

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

How long has the bug existed in the product?

Do regression tests exist for this issue?

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

When will a tested fix be ready for integration?

3. Send mail to gf-cc@sun.com

To: gf-cc@sun.com
Subject: 3.1 Change Request

Component Name: XXXXX
Issue: https://github.com/javaee/glassfish/issues/NNNNN

4. An approver will review the issue:
4.1 The approver will remove the 3_1-review tag.
4.2 If it is approved the 3_1-approved tag will be added to the issue. The Fix Version/s will be changed to the appropriate milestone with an "Approved" comment added to the issue.
4.3 If it is rejected the 3_1-exclude tag will be added to the issue. If the deferred issue is a candidate for the next update release then the 3_1-next tag will be added.
4.4 The approver will reply to the change request mail (including the alias) indicating their position on the issue.

Stage 2 (Integrate the change)

After the issue has been approved for the release you may develop the fix. Once the fix is available choose a peer to review the code. The reviewer should put their review comments in the issue. Once the pertinent changes from the review have been addressed and the appropriate pre-integration tests have successfully passed the issue may be committed.

The commit comment must include the issue number, name of the code reviewer and name of the person who approved the change request. It is also a good practice for the commit comment to also include a summary of what you fixed and possibly how you fixed it.

The issue must be updated to reflect the revision number the issue was resolved in. At this time the fix must be integrated to both the trunk and the 3.1 branch. Record both revision numbers in the issue when the issue is closed.

.