- Understand key dates
- Scrub your bugs
- Get approval for your fixes (if Change Control is in effect)
- Fix your bugs
- Mark bugs to be documented in the release notes
- Determine the doc impact of your bugs
- See the FAQ if you have any questions
|B1 until 12/12/2011||Open bug fixing|
| 12/12/2011 Midnight
||Soft Code Freeze. Change Control starts.|
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.
- Review all of your open bugs using the 3.1.X Bug Fix Criteria, especially those:
- on the unscrubbed P1-P3 list (this list needs to go to 0) [just your unscrubbed bugs]
- with high vote counts .
- you have fixed in the trunk but not in the 3.1.x branch
- bugs you may have in BugDB
- 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).
- 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
- 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
- If you want to fix the bug in 3.1.2 then add the following tag: 3_1_2-review
- 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
|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.|
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.]
After build B14 you must get approval before integrating a bug fix into the 3.1 branch. Here is the process:
- Add the 3_1_2-review tag to the issue.
- 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:
- Send mail to firstname.lastname@example.org (or email@example.com, or firstname.lastname@example.org) :
- The bug will be reviewed and the 3_1_2-review tag will be removed.
- 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.
- If it is rejected then the 3_1_2-exclude tag will be added to the issue.
- The decision(approved/rejected) will be emailed to the issue owner.
- Once the bug fix is approved please integrate it as described in How to Fix a Bug in 3.1.2 .
- Get the fix code reviewed by a peer and other module leads if the fix crosses module boundaries.
- Make sure that you are not introducing any FindBugs errors.
- Integrate fix into 4.0 trunk (if applicable, fixes must be checked into trunk first) and update bug:
- Add comment to bug containing trunk svn revision number, file list and comments.
- Set Fix Version to the 4.0 build
- If Change Control is in effect get approval to integrate the fix into 3.1.2 . See Bug Fix Approval Process
- Integrate fix into 3.1.2 branch and update bug:
- Add comment to bug containing branch svn revision number, file list and comments.
- 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).
- If the bug fix impacts documentation then create a documentation subtask for the bug.
- 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.
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
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:
- Edit the bug you are fixing
- Click on "create sub-task"
- 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.
- Set sub-task Component to docs
- 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).
- 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?
- 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.
- What if I'm doing a bug fix that requires a minor enhancement like a new CLI option? Is that OK?
- This is probably OK. Just make sure to create a documentation subtask for the bug so docs knows to document the enhancement.
- 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?
- 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.
- I can't edit fixVersion in a Closed bug
- 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.
- Can I add a new product feature in 3.1.2?
- 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.
||Change Control in effect and bug is approved for the indicated release.|
|| Bug is excluded from 3.1.2 but should be considered for a future 3.1.x release.
|| 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.
| Bug should be considered for a future release.
|| Unclear how this tag is used.
|| Change Control is in effect and the bug is being targeted for 3.1.2
|| 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.
|| Bug is a test blocker. Typically set by QA.
|| 508 compliance bug. Typically set by QA.
|CTS-GFv3.1|| CTS compliance bug. typically set by CTS team.