GStreamer on TI DaVinci and OMAP

Defect Tracking

If you find a reproducible problem, we want to know about it. The following is a description of the lifecycle of a defect tracker - the details on what happens to defects you enter.

Try repeating the steps that led to the defect. Be sure to capture as much detail as possible to enable a developer to reproduce the defect.

Entering New Defect

Please use the tracker link to the left to add a new defect. The tracker you add needs the following:

Provide a meaningful short summary of the defect that will be used as the defect title.

Set tracker type to defect.

List known devices (OMAP3, DM365, etc) exhibiting the defect. Often you will just set this to the hardware you are currently using. Later a developer with more hardware available may include other devices. If you test on a device and the defect does not occur, please note that in your comments.

Specify plug-in version exhibiting defect, such as released code, trunk, trunk with patches, etc.

In the details section, fill out the template shown below. Be sure to include the steps needed to reproduce the error, the version of the DVSDK being used, etc.

Attach any media files needed to reproduce the error. Be sure you have the copyright holder's permission to post the media files on the Internet.

Developer Initial Defect Review

A developer will review your defect entry, making sure we have all the needed information, and get the defect on its way to being resolved.

Accept or reject (close) the defect. A defect may be rejected, for example, if it was found on an older version of the code. As a follow-up, a comment needs to be added explaining why the defect was rejected.

Assign to an engineer if appropriate.

Prioritize if priority is obvious.

Target a release date if appropriate.

Developer Defect Resolution

Depending on the circumstances, the assigned engineer may resolve the defect by reassigning the defect to a more appropriate engineer, or may find and fix the defect.

Reassign, reprioritize, or target a different release as appropriate once the defect is understood.

Test on other devices as necessary, updating the tracker on which devices are effects and making a follow-up note listing devices that are not effected.

If possible, create a test case to demonstrate defect and add test to release test suite.

Find the root cause of the defect, fix, and test.

Create a patch and attach patch to the defect tracker.

Peer Patch Review

Each patch will be reviewed by at least one other developer, ideally two. Once the patch has been reviewed,

Each developer reviewing the patch needs to add a follow-up comment stating the patch has been reviewed.

Update the trunk with the patch.

Change the defect tracked state to checked-in.

Trunk Release

Periodically, the code is tested on all supported devices and released. As part of the release process, fixed defects included in the release are closed as follows: