Difference between revisions of "CDT/Obsolete/Bugs"

Latest revision as of 16:21, 16 January 2020

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

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]