ITK/Procedure for Contributing Bug Fixes: Difference between revisions
Daviddoria (talk | contribs) |
Hjmjohnson (talk | contribs) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Historical}} | |||
Please see the [https://itk.org/ITKSoftwareGuide/html/Book1/ITKSoftwareGuide-Book1ch10.html#x49-16300010 Software Process section of the ITK Software Guide] and our [https://github.com/InsightSoftwareConsortium/ITK/blob/master/CONTRIBUTING.md CONTRIBUTING guide]. | |||
= The Sad Truth = | = The Sad Truth = | ||
| Line 48: | Line 52: | ||
== Entering a bug == | == Entering a bug == | ||
* | * https://insightsoftwareconsortium.atlassian.net/secure/Dashboard.jspa | ||
# [https:// | # [https://insightsoftwareconsortium.atlassian.net/secure/Dashboard.jspa Obtain an account for the issue tracker] | ||
# [https:// | # [https://insightsoftwareconsortium.atlassian.net/secure/Dashboard.jspa Log in to the issue tracker] | ||
# [https:// | # [https://insightsoftwareconsortium.atlassian.net/secure/Dashboard.jspa Report the issue] | ||
Be sure to select the Project in the upper left hand corner. Fill in every entry possible in the report. If you know who should handle this report, then select the developer from the '''Assign To''' pull down. As the issue progresses through its life cycle, you will be notified via e-mail. | Be sure to select the Project in the upper left hand corner. Fill in every entry possible in the report. If you know who should handle this report, then select the developer from the '''Assign To''' pull down. As the issue progresses through its life cycle, you will be notified via e-mail. | ||
Latest revision as of 19:16, 20 March 2018
 | This page is currently inactive and is retained for historical reference. Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as the village pump. |
Please see the Software Process section of the ITK Software Guide and our CONTRIBUTING guide.
The Sad Truth
Most bugs are introduced as secondary effects from attempts to fix other bugs
This procedure is intended to prevent such secondary effects from happening.
Reporting a Bug
Anyone can report a bug. ITK uses JIRA for bug tracking.
A Bug's Life
A bug progresses through the following stages in roughly this order.
| Stage | Who's Responsible | Description |
| new | Anyone can report a bug | The description of the bug |
| assigned | Anyone can assign a bug | A developer has been assigned to the bug |
| feedback | Assignee and Reporter | The Assignee requests additional info on the bug |
| confirmed | Assignee | The Assignee can reproduce the bug |
| resolved | Assignee | The Assignee fixed the bug |
| closed | Reporter(preferred) or Assignee | The resolution is acceptable |
Entering a bug
Be sure to select the Project in the upper left hand corner. Fill in every entry possible in the report. If you know who should handle this report, then select the developer from the Assign To pull down. As the issue progresses through its life cycle, you will be notified via e-mail.
The issue report should be very clear, and when possible it should be accompanied with a small piece of code (and data) that permits to easily replicate the problem. If you have a suggested fix, please include it.
Fixing a Bug
Follow our Git instructions to get started with development. The following steps take place at this point of the Git instructions.
Add a test if necessary
When a bug is found, the following questions should be raised
Why wasn't it found before?
The most likely answer is that we were missing a test for the specific case in which the bug is visible. In other words, the bug passed unnoticed due to the lack of testing some special case.
Therefore a test for that specific case must be added, before attempting to fix the bug. This test will ensure that once the test is fixed, it will never reappear without being noticed.
As soon as the test is added, it will be failing, showing that the test actually detects the problem.
Fix the code in your local build
Modify the code of your local build until the new test is passing.
Submit an experimental build
This is necessary for detecting secondary effects that may result from the code fixes.
It is IMPOSSIBLE to anticipate secondary effects. The code modifications that seem to be the most innocuous, commonly result in plenty of secondary effects. Do not rely on your "mental compilation" skills. The only way to verify that the "code fix" doesn't break something else is to actually run a full Experimental build.
Verify that the code changes do not produce any compilation problems, or make any other tests fail.
Commit the code
- Provide a commit message with a clear description of the bug fix
- This comment should be clear enough for other developers to understand the problem five years from now.
- It should be of the format "BUG: your description (ITK-#####)" where ##### in the number of bug ID in JIRA. This will provide a link from the dashboard back to JIRA.
Link the commit in the bug report
- Go to the bug report
- Insert as comment the gitweb link to the commit.
- http://itk.org/ITK.git
Wait for several continuous builds
- In order to verify that
- the problems was fixed also in other platforms, and
- the code fix doesn't produce compilation or link problems in other platforms
- e.g. SGI, Borland, VS6,7,8, Icc 8,9, builds with shared libraries, and builds with Tcl, Python and Java wrapping.
Wait for a new Nightly submission
A full coverage of platforms requires to wait until the next day to see all the Nightly submissions.
Close the Bug
If the Nightly tests are clean (as far as this commit is concerned) then close the bug, and mark it as fixed.
