Skip to main content

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.

Jump to: navigation, search

DSDP/DD/Bug Process

< DSDP‎ | DD
Revision as of 01:35, 23 August 2007 by Pawel.piech.windriver.com (Talk | contribs) (Queries)

Queries

Planning and Future Work

By Sub-Group / Contributor

Sub-group Assignee
SPIRIT Anthony Berent (Arm)
Memory Ted Williams (Wind River)
DSF Pawel Piech (Wind River)
Randy Rohrbach (Wind River)
Ted Williams (Wind River)
GDB Veenu Verma (Ericsson)
Marc Khouzam (Ericsson)
Francois Chouinard (Ericsson)

Bug Life Cycle

Everybody - users and developers - may apply for a Bugzilla account and submit bug reports or enhancement requests.

Once the bug report is filed, contributors and committers work on it, including updates to bug status. All users may contribute to the discussion by adding comments (but typically not change the status fields). The Eclipse Process Guidelines contain some good information and a handy diagram for understanding the lifecycle of an issue in Bugzilla.

How bugs are ASSIGNED

  1. All bug should be created with the "Assigned To" field set to dd.general-inbox@eclipse.org. This allows everyone watching the list to observe bug activity.
    • Component owner, which is normally the leader of the sub-project owns the component, confirms that the bug is valid and assigns it to a committer or contributor.
    • Alternatively, if a contributor created the bug for an issue that was discovered and immediately fixed, the contributor should assign the bug to himself.
    • Plan items and other composite enhancements can stay assigned to the inbox, but have their state changed to ASSIGNED when a commitment is made to fix them.
  2. When the contributor can commit to a fixing a bug, he changes the state to ASSIGNED and sets a target milestone.

How bugs are FIXED and VERIFIED

  1. When a committer or contributor has completed fixing the bug, he should post a patch with the fix to the bug.
  2. A committer commits the changes to CVS. A contributor can request a committer to apply the patch.
  3. The committer changes the bug status to FIXED and request for the component owner or another committer to review the fix.
  4. The reviewer should review the changes and optionally confirm program behavior and mark the bug as VERIFIED.

How bugs are CLOSED

  1. With each milestone build, the VERIFIED bugs are logged and marked as CLOSED.

Back to the top