CDT/Obsolete/Bugs

Note: The contents of this page is obsolete, but it may still contain some interesting tid-bits. Please see the Development_Resources/HOWTO/Bugzilla_Use for current information on Bugzilla and the QA Contact field in Bugzilla itself for owner of the component with ultimate responsibility

Bug Life Cycle

All users may contribute to the discussion by adding comments (but typically not change the status fields). The Eclipse Process Guidelines contains more general information and diagram on bug lifecycle information and a handy diagram. Once the bug report is filed, contributors and committers work on it, including updates to bug status.

Filing

Everybody - users and developers - may apply for a Bugzilla account and submit bug reports or enhancement requests. Bugs are created in NEW state and are assigned to the selected component's inbox email (e.g. cdt-debug-inbox@eclipse.org). Users and developers who would like to be notified of all new bugs on a component can configure their bugzilla preferences to watch the component inbox.

Triage

Component owners are ultimately responsible for triaging bugs assigned to their component, although anyone is welcome to help with this task. Bugs in NEW state are reviewed to determine whether the bug is valid and not a duplicate of an existing bug.

• If the bug is valid, the developer changes the bug state to ASSIGNED, while leaving the "Assigned To:" field set to the component inbox email.
• If the bug is determined not to require any further action, it's state is immediately changed to RESOLVED, with one of the following resolutions : DUPLICATE, INVALID, WONTFIX, NOT_ECLIPSE, WORKSFORME.
• If the bug doesn't contain enough information to determine what to do with it, a "needinfo" keyword will be added along with a comment on what need additional information is needed.

Fixing

• A committer who intends to fix a given bug, takes the bug by changing the Assigned to: field, changes its status to ASSIGNED and sets the target milestone when he intends to commit the fix.

Reviewing

• Before committing the fix, the committer should create a patch with the changes that are applied to fix the bug. This patch should be attached to the bug with the fix comment.
• The committer should request for another committer or contributor to review the bug. This is done by adding a review flag to the bug (set the field to '?') with the name of the developer being requested to review the bug, or of the component's inbox. Note that there is also a review flag per attachment. Here we are specifically talking about the review flag at the bug level.
• Once the patch is attached and the review requested, the fix can be committed and the bug should be marked as RESOLVED/FIXED.
• Upon reviewing the fix, the reviewing committer can change the review flag to a "+" or "-". The review can be omitted if the component has only one active developer. Any comments from the review should be fixed as another commit to the same bug with the new patch also attached.

Query: All Open CDT Bugs

Verifying

• Once the bug is fixed, the user that requested the bug to be fixed, should download the build which includes the fix and try it. If the issue is indeed addressed, the user should mark the bug as VERIFIED.
• Alternatively, during a manual milestone testing cycle, a tester may also confirm that the bug is fixed and mark is VERIFIED.

How bugs are CLOSED

• When a release is shipped, all bugs filed in that release and resolved with resolutions: VERIFIED, DUPLICATE, WONTFIX, NOT_ECLIPSE, WORKSFORME are marked as CLOSED.
• Also when a release is shipped, all bugs filed in previous release, with resolution FIXED, will be 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.

Components

Component	Owner	Description
cdt-autotools	Jeff Johnston (jjohnstn@redhat.com)	Autotools project creation and related tools
cdt-build	Andrew Gvozdev (angvoz.dev@gmail.com)	C/C++ build general, error parsers, binary parsers, project creation and conversion
cdt-build-managed	Chris Recoskie (recoskie@ca.ibm.com)	Managed build - UI and core
cdt-core	Doug Schaefer (cdtdoug@gmail.com)	Very general component - something that does not fit in the other components
cdt-codan	Elena Laskavaia (elaskavaia.cdt@gmail.com)	Codan Static Analysis
cdt-debug	Ken Ryall (ken.ryall@nokia.com)	General debug and launch - usually can be classified further as sub-components below
cdt-debug-cdi	John Cortell (john.cortell@freescale.com)	Debug CDI implementation (Classic)
cdt-debug-cdi-gdb	Elena Laskavaia (elaskavaia@qnx.com)	Debug GDB/MI implementation based on CDI
cdt-debug-dsf	Pawel Piech (pawel.piech@windriver.com)	Debug DSF implementation (New in CDT 6.0)
cdt-debug-dsf-gdb	Marc Khouzam (marc.khouzam@ericsson.com)	Debug GDB/MI implementation based on DSF
cdt-debug-hardware	John Dallaway (john@dallaway.org.uk)	GDB Hardware Debugging - including JTAG devices
cdt-doc	Doug Schaefer (cdtdoug@gmail.com)	All CDT User docs
cdt-editor	Anton Leherbauer (Anton.Leherbauer@windriver.com)	C/C++ Code Editor
cdt-indexer	Markus Schorn (Markus.Schorn@windriver.com)	C/C++ Indexer - all pr based on missing wrong/missing declaration/definition and references for search and navigation
cdt-other	Doug Schaefer (cdtdoug@gmail.com)	Other, including cdt home page, wiki pages and misc stuff
cdt-parser	Markus Schorn (markus.schorn@windriver.com)	C/C++ Parser for editor syntax highlighting or indexer
cdt-refactoring	Sergey Prigogin (eclipse.sprigogin@gmail.com)	C/C++ code refactorings
cdt-releng	Doug Schaefer (cdtdoug@gmail.com)	CDT build and release management
cdt-source-nav	Markus Schorn (Markus.Schorn@windriver.com)	Indexer based tools such as Call Graph and Type Hierarchy

Features

In addition to component selected from the component field, CDT 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 CDT bug database:

• General
  • [test] unit tests
  • [Accessibility] (TODO)
  • [I18N] (TODO)
  • [docs] user and design documentation (may need to split this feature)
• Debugger
  • [breakpoints]/[bp] breakpoint support
  • [concurrency]/[async] utilities for asynchronous programming, mostly extending functionality from java.util.concurrent
  • [console]/[con] console view support
  • [debug view]/[dv] debug view (aka launch view) support
  • [disassembly]/[dis] disassembly view support
  • [expressions]/[expr] expressions view support
  • [launch] launch configurations, delegates, UI, etc.
  • [memory]/[mem] memory view support
  • [modules]/[mod] modules view support
  • [registers]/[reg] register view support
  • [run control]/[rc] support for run control commands
  • [source lookup]/[src] mapping debugger sources to the host file system, opening the editor
  • [stack]/[stk] stack display
  • [symbols]/[sym]support for browsing symbols in modules view
  • [variables]/[var] variables view support
  • [menu] Bugs related to main menu, context menus, and toolbars.
  • [reverse] Reverse debugging (stepping backwards)
  • [hover] Debug hover in editor
• DSF
  • [cdi] Features which exist in CDI-GDB integration but are missing in DSF-GDB.
  • [update] configurable update modes used in variables, expressions, registers views
  • [number format detail][#fmt] detail pane showing different number formats, used in variables, registers, and expressions views
  • [commands]/[cmd] infrastructure (control, caches, etc.) for managing debugger back-end commands and their results
  • [services]/[ser] infrastructure for registering, grouping, referencing services, based on OSGi services
  • [examples]/[ex] DSF Examples
  • [pda] DSF PDA debugger example integration
  • [data model]/[dm] DSF APIs for services level data model
  • [view model]/[vm] DSF integration with debug platform flexible hierarchy view APIs
• DSF-GDB
  • [non-stop] Non-stop multi-threaded debugging in GDB
  • [multi-process]/[mp] Multi-process debugging in GDB
• to classify (gathered from a query):
  • [AST]
  • [AST Binding]
  • [Binary Parser]
  • [Bindings C++]
  • [Bindings]
  • [Build UI]
  • [Build]
  • [C++ Bindings]
  • [C++ Length]
  • [C++ Browsing]
  • [C++ Offsets]
  • [C++ Parser]
  • [C++ Projects View]
  • [C++ Search]
  • [C99 Parser]
  • [Call Hierarchy]
  • [CCE]
  • [Class Browser]
  • [CModel]
  • [Content Assit]
  • [CTags Indexer]
  • [DOM AST]
  • [Editor]
  • [Editor Parser]
  • [Formatter]/[formatter]
  • [IBinding]
  • [Include Browser]
  • [Indenter]
  • [Indexer][indexer]/[Index]
  • [Internal Builder]
  • [IProblems]
  • [Macro Exporer]
  • [Managed Build]
  • [MBS]
  • [New Class Wizard]
  • [New Content Assist]
  • [New Project Wizard]
  • [Outline View]/[Outline]
  • [Parser/AST]
  • [Parser2]
  • [Parser]
  • [Preprocessor]
  • [Preferences]
  • [Project Model]
  • [Refactoring]
  • [RPM]
  • [Scanner Config]
  • [Scanner Discovery]
  • [Scanner]
  • [Search]
  • [Template Enginve]
  • [Templates]