GuidelinesOnBugFixesFor312

Skip to end of metadata
Go to start of metadata

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

B1 until 12/12/2011 Open bug fixing
12/12/2011 Midnight
Soft Code Freeze. Change Control starts.

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

Unscrubbed P1-P3 Bugs Unscrubbed P1-P2 3.1.2 bugs
This needs to go to 0 before 3.1.2 releases
Release Notes Bugs that have been tagged for Release Notes and are not fixed in the 3.1.X branch  
Votes > 2 Open bugs that have # of votes > 2  
Fixed in the trunk but not in the 3.1.x branch Bugs we think have been fixed in the trunk, but not in the branch.  
Unscrubbed P1-P3 Features Unscrubbed 3.1.2 rfes
3_1_1-next Bugs Open bugs that have the 3_1_1-next tag that have not been fixed in 3.1 branch.
3_1-next Bugs Open bugs that have the 3_1-next tag. This does not include bugs targeted (fixVersion) for 3.2 or later since, presumably, the owner is intending to fix the bug in 3.2 or later - not in branch.
Fixed bugs with bad Fix Versions Bugs that have a Resolution of Fixed, but don't have a valid Fix Version. It would be good to start cleaning these up.

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: http://java.net/jira/browse/GLASSFISH-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

Tag Description Notes
3_1_2-approved
Change Control in effect and bug is approved for the indicated release.
3_1_2-exclude
Bug is excluded from 3.1.2 but should be considered for a future 3.1.x release.
 
3_1_x-exclude
Bug is excluded from all 3.1.* releases.
Used for bugs that don't apply to 3.1.x or bugs we don't plan on ever fixing in 3.1.x
future-exclude Bug is not applicable to any 3.X or 4.X release (HADB for example).
This tag is not expect to be used much going forward. 
3_1-next
3_1_1-next
Bug should be considered for a future release.
Unclear how this tag is used.
3_1_2-review
Change Control is in effect and the bug is being targeted for 3.1.2

3_1_2-release-notes
Bug should be documented in the 3.1.2 release notes

3_1-regression Bug is a regression from a previous release. Typically set by QA.
 
3_1-upgrade Bug is an upgrade bug. Typically set by QA.
 
3_1-blocker
Bug is a test blocker. Typically set by QA.
 
508
508 compliance bug. Typically set by QA.
 
CTS-GFv3.1 CTS compliance bug. typically set by CTS team.
 

11) Reference

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.