1) Bug fixing in 3.1.2: What do I do?

1. Understand key dates
2. Scrub your bugs
3. Get approval for your fixes (if Change Control is in effect)
4. Fix your bugs
5. Mark bugs to be documented in the release notes
6. Determine the doc impact of your bugs
7. See the FAQ if you have any questions

2) Key Dates

3.1.2 Schedule

3) Bug Scrubbing

Important! We are using the Jira fixVersion field in a number of our queries so it needs to be accurate. fixVersion is a multi-value field. If a bug is fixed in the trunk and the 3.1.x branch it should have fixVersion set to both the trunk version and the 3.1.x version.

Please make sure that you provide as detailed justification as possible for any of your activity below through Jira's comments section.

1. Review all of your open bugs using the 3.1.X Bug Fix Criteria, especially those:
   1. on the unscrubbed P1-P3 list (this list needs to go to 0) [just your unscrubbed bugs]
   2. with high vote counts .
   3. you have fixed in the trunk but not in the 3.1.x branch
   4. bugs you may have in BugDB
2. If a bug is already fixed in 3.1.x, but appears on the unscrubbed list then make sure the fixVersion includes an appropriate 3.1.x version (in addition to the trunk version).
3. If a bug is not applicable to 3.1.x or you never plan on fixing it in a 3.1.x release then add the following tag: 3_1_x-exclude
4. If you are not going to fix it in 3.1.2 but may fix it in a future 3.1.x release then either lower the priority to P4 (if appropriate) or add the following tag: 3_1_2-exclude
5. If you want to fix the bug in 3.1.2 then add the following tag: 3_1_2-review
   1. If the release is under Change Control then get approval before checking in the fix.
   2. If the release is not under Change Control, then you do not need to get approval
   3. More details in: How to fix a bug in 3.1.2
6. If you are not going to fix the bug in 3.1.2 but want it mentioned in the 3.1.2 release notes then also add the following tag: 3_1_2-release-notes

Helpful Queries

4) Bug Fix Criteria

What bugs should you fix in 3.1.2? Bugs that:

• are P1 or P2, since those bugs should typically be fixed ASAP.
• impact product security
• represent a CTS failure
• are a regression of functionality or performance from a prior release
• introduce an incompatibility
• are likely to generate customer support calls
• are an in-your-face issue that will impact a majority of users
• are directly reported by the community or have been created from forum data.
• are release noted from 3.1.1
• were deferred from 3.1.1

For more information on the 3.1.2 release including content and release drivers please see the 3.1.2 Home Page.

5) Bug Fix Approval Process (Change Control)

After build B14 you must get approval before integrating a bug fix into the 3.1 branch. Here is the process:

1. Add the 3_1_2-review tag to the issue.
2. Add a comment to the issue providing justification on why we should consider this for 3.1.2. Your write up must answer the following questions:

   * What is the impact on the customer of the bug?
   
    How likely is it that a customer will see the bug and how serious is the bug?
    Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
   
   * What is the cost/risk of fixing the bug?
   
    How risky is the fix? How much work is the fix? Is the fix complicated?
   
   * Is there an impact on documentation or message strings?
   
   * Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
   
   * Which is the targeted build of 3.1.2 for this fix?
   

3. Send mail to dev@glassfish.java.net (or scatari@java.net, or jfdipol@java.net) :
   Email Template

   To: dev@glassfish.java.net
   Subject: 3.1.2 Change Request
   
   Component Name: XXXXX
   Issue: https://github.com/javaee/glassfish/issues/NNNNN
   
   

4. The bug will be reviewed and the 3_1_2-review tag will be removed.
5. If it is approved the 3_1_2-approved tag will be added to the issue. The Fix Version/s will be set to the appropriate milestone with an "Approved" comment added to the issue.
6. If it is rejected then the 3_1_2-exclude tag will be added to the issue.
7. The decision(approved/rejected) will be emailed to the issue owner.
8. Once the bug fix is approved please integrate it as described in How to Fix a Bug in 3.1.2 .

6) How to Fix a Bug in 3.1.2

1. Get the fix code reviewed by a peer and other module leads if the fix crosses module boundaries.
2. Make sure that you are not introducing any FindBugs errors.
3. Integrate fix into 4.0 trunk (if applicable, fixes must be checked into trunk first) and update bug:
   1. Add comment to bug containing trunk svn revision number, file list and comments.
   2. Set Fix Version to the 4.0 build
4. If Change Control is in effect get approval to integrate the fix into 3.1.2 . See Bug Fix Approval Process
5. Integrate fix into 3.1.2 branch and update bug:
   1. Add comment to bug containing branch svn revision number, file list and comments.
   2. Make sure Fix Version has the correct 3.1.2 build set in addition to the trunk build (be careful not to clear the trunk build version).
   3. If the bug fix impacts documentation then create a documentation subtask for the bug.
   4. Close bug as resolved

Note: due to the reorganization of the source in the trunk (due to the nucleus split) back porting of fixes from the trunk to the 3.1.X branch has become more difficult. Specifically, "svn merge" doesn't work like it has for previous releases.We hope to come up with some tips to help folks deal with this difficulty shortly.

7) Release Notes

If a bug needs to be documented in the 3.1.X release notes then add the following tag to the bug: 3_1_2-release-notes

8) Documentation Impact

If a bug fix impacts documentation, for example if you are adding a new CLI flag, or some command output changes, then you must create a subtask for the documentation team. To do that:

1. Edit the bug you are fixing
2. Click on "create sub-task"
3. Enter information for the sub-task. This is similar to creating a new issue, except that it is now associated with the bug you fixed.
   1. Set sub-task Component to docs
   2. It is acceptable to refer to the parent bug for details concerning the change (assuming the parent bug has sufficient details for the tech writers).

9) FAQ

1. I'm scrubbing my bugs and I have some bugs that I want to fix in 3.1.2. How do I indicate that I want to fix them in 3.1.2?
   1. Between now and B13 you do not need to do tag them with anything special. The bugs will stay on the "unscrubbed list" indicating you intend to fix them in 3.1.2. After B13 we will enter Change Control and you will need to tag bugs you want to fix in 3.1.2 with 3_1_2-review. At that time we will press to drive the "unscrubbed list" to 0.
2. What if I'm doing a bug fix that requires a minor enhancement like a new CLI option? Is that OK?
   1. This is probably OK. Just make sure to create a documentation subtask for the bug so docs knows to document the enhancement.
3. I fixed a bug in both the trunk and the 3.1.x branch. The bug is marked "fixed" but it is still appearing in the unscrubbed list. What's going on?
   1. The fixVersion is probably not set correctly on the bug. It is a multi-valued field. Make sure you have selected both the trunk (4.0) and branch (3.1.x) version in the scrolling list. If the fixVersion does not contain a 3.1.x branch version then we don't know the bug has been fixed in the branch.
4. I can't edit fixVersion in a Closed bug
   1. Correct. When a bug is Closed you can't edit some fields. You need to Re-open the bug, edit it, then Close it. On the other hand bugs that are in Resolved state can be edited.
5. Can I add a new product feature in 3.1.2?
   1. Generally no. There is a list of approved features for 3.1.2. If your feature is not on that list then you can't add it to the release.

10) Summary of Issue Tags

11) Reference

• 3.1.2 Home Page
• 3.1.2 Schedule
• 3.1.2 Internal Page