Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Debug/Developers
Bug Lifecycle
All bugs for the Debug components follow the same lifecycle. All committers and contributors must adhere to this lifecycle to ensure all defects are tracked and handled accordingly.
- NEW - All newly filed bugs start out in the NEW state.
- DUPLICATE/INVALID/WORKSFORME/WONTFIX - If a bug is a duplicate of another bug or if a Debug committer decides that no code changes will be made for the bug, the bug is resolved immediately with an explanation. Unless the bug is REOPENED for some reason, this is the end of the road.
- ASSIGNED - Once a bug has been validated by a Debug committer, it is moved to the ASSIGNED state. When a committer is going to work on a bug, they typically reassign it to themselves.
- RESOLVED-FIXED - Bugs are marked as RESOLVED-FIXED once a patch for the bug has been added to the bug report and committed to CVS. When requesting that someone verify a bug, we set the review flag for the person we want to verify it and add them to the CC list, if not already present. If for some reason the person you want to verify the bug does not have privileges to set the review flag, mention them in a comment asking to verify the bug and ensure they are on the CC list.
Bugzilla is picky about the state changes it allows, so we follow these steps to maximize efficiency:
- Reassign the bug to the Debug committer who will fix the bug.
- Create a patch of the proposed fixes for the bug and attach it to the bug report.
- Commit the code changes to CVS.
- Using the REVIEW flags add the other committer(s) who are to verify the bug (with the '?' flag).
- Add the committer(s) involved in the review to the CC list - to ensure they are notified of a review request.
- Mark the bug RESOLVED-FIXED with a request to verify.
- VERIFIED-FIXED - Bugs are marked as VERIFIED-FIXED once someone verifies the fix that was checked into CVS. Bugs are always verified by a Debug committer other than the person who checked in the fix. The verifier makes sure that the original problem is fixed and also looks at the code for any obvious errors. This verification step ensures that all code changes are looked at by at least two pairs of eyes.
Test Passes
Before every milestone release the Debug team does an intense one-day test pass where we test all of the functionality of the Debug components. We try to check everything to make sure 100% of the functionality is available in every major release. In addition, we try odd use cases and unusual code to ensure our code is as robust as possible.
To organize the test pass, we follow a test script. The script defines a basic overview of what must be tested in each section.
If you would like to help out during a test pass, contact us via our mailing lists. Before the test pass, let us know what platform you are going to test on and what sections you are planning to test. If you have any questions about how to test some area, we would be happy to help explain.