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

Difference between revisions of "DSDP/DD/Bug Process"

< DSDP‎ | DD
m (By Feature)
m (By Feature)
 
Line 81: Line 81:
 
: variables view support
 
: variables view support
 
; cdi : Features which exist in CDI-GDB integration but are missing in DSF-GDB.
 
; cdi : Features which exist in CDI-GDB integration but are missing in DSF-GDB.
 +
; menu : Bugs related to main menu, context menus, and toolbars.
  
 
== Bug Life Cycle ==
 
== Bug Life Cycle ==

Latest revision as of 11:31, 25 September 2008

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)

By Feature

In addition to component selected from the component field, DD bugs are optionally categorized using the feature name that the bug affects. The feature names are listed in bug's summary in square brackets ('[]').

Following are the features currently used in the DD bug database:

breakpoints
breakpoint support
commands
infrastructure (control, caches, etc.) for managing debugger back-end commands and their results
concurrency
utilities for asynchronous programming, mostly extending functionality from java.util.concurrent
console
console view support
debug view
debug view (aka launch view) support
disassembly
disassembly view support
docs
user and design documentation (may need to split this feature)
expressions
expressions view support
launch
launch configurations, delegates, UI, etc.
memory
memory view support
modules
modules view support
number formats detail
detail pane showing different number formats, used in variables, registers, and expressions views
registers
register view support
run control
support for run control commands
services
infrastructure for registering, grouping, referencing services, based on OSGi services
source lookup
mapping debugger sources to the host file system, opening the editor
stack
stack display
standard model
compatibility with standard debug model
symbols
support for browsing symbols in modules view
tests
unit tests
update policy
configurable update modes used in variables, expressions, registers views
variables
variables view support
cdi 
Features which exist in CDI-GDB integration but are missing in DSF-GDB.
menu 
Bugs related to main menu, context menus, and toolbars.

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. Normally a bug should be created and assigned to the DD inbox: dd.general-inbox@eclipse.org. However, when a developer creates a bug that he/she intends to work on, he may set the "Assigned To" field to himself. The project is configured to add dd.general-inbox@eclipse.org to bug's CC list, so all inbox listeners will get notified of the bug anyhow.
    • If the bug is in the inbox, the 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 "Assigned To" field of the bug to another committer who is to review the fix.
  4. The committer fixing the bug changes the bug status to FIXED.
  5. 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 in build notes and marked as CLOSED.

=== Bugs in maintenance release

  • We will only have maintenance releases for latest major release.
  • If a bug is determined to be severe enough to be addressed in the maintenance release, that bug is to be re-opened and targeted for that release.
  • Part of the bug review is to make sure that the fix is applied to both branches.

Back to the top