Bug tracking system

This page is deprecated. We do not use Mantis anymore.

Our bugtracker is designed for two tasks : bugs and feature requests management.

This is most efficient way to ensure bugs to get fixed: As long as a bug is not fixed, its “entry” stays in the bugtracker. Unlike forum posts, it's impossible for bugs entries to be forgetten about.

Feature requests are also managed in the bugtracker. A feature request is just like a bug report with a severity set to “feature”.

The bugtracker is using Mantis. This tool is has lots of useful features. For example, we can automatically generate a list of bugs corrected and features added for a given release, see it in action.

The difference between the forum and the bugtracker is the level of specialization. While the forum is a very generic discussion tool, the bugtracker is dedicated to tracking tickets (bug correction or feature request). If we were using the forum for bugtracking, users would have to be much more rigourous. With the bugtracker, the tool imposes rigour upon users. Users just have to fill in a full set of information and follow the established process.

One of the purposes of the bugtracker is to keep information useable in the long term.

What we can do with a bugtracker we can't do with a forum:

• Follow state of a bug
• Know who is in charge of fixing it
• Know who is also interested in the bug (anybody can subscribe to a bug)
• Know in which release/build the bug was fixed

• Registering is mandatory to submit bugs. No account is required to read the bug database. The bugtracker, forum and wiki do not share user accounts.
• When reporting an issue, fill as many fields as possible and be precise.
  • Project see relative section.
  • Product version is useful only if you report a bug. Useless for feature request. When reporting a bug on development trunk, give the corresponding Subversion ¹⁾ revision.
  • Target version is a field reserved for Talend team.
• When a developer resolves a bug, he has to follow the development guidelines for Subversion commit logs, this way an automatic note will be added in the bugtracker
• When the status goes from assigned to anything else, the resolution must be changed to fixed and the field fixed in version must be filled (mandatory).

In the bugtracker, the following shortcuts are available:

• bug: 123 links to an existing bug (bug number 123)
• topic: 123 links to a topic (id 123) in the forum
• svn_<project>:<revision> (without space after ”:”) automatically creates a link to Subversion online viewer. <project> is one of “tos”, “top” or “tdq” and <revision> is the revision number. For example svn: 968 gives [Subversion] r968. Theoretically, you should not use the svn shortcuts because links to Trac are created automatically.

+--------------------+
|        new         | Submitted and being read by developers
+--------------------+
          |
+------------------------+
| feedback from reporter | Discussion engaged, waiting for reporter reply
+------------------------+
          |
+----------------------+
| feedback from Talend | Discussion engaged, waiting for Talend reply
+----------------------+
          |
+--------------------+
|      confirmed     | A developper has taken the entry and will implement a solution as soos as available
+--------------------+
          |
+--------------------+
|      assigned      | The developper is currently working on the entry
+--------------------+
          |
+--------------------+ The bug was fixed (the feature was added) and the developer asks someone else to verify.
|      toVerify      | (Bug or feature available on our SubVersion)
+--------------------+ This step is not mandatory.
          |
+--------------------+ The bug was fixed (the feature was added) and needs some documentation before being closed.
| resolved/needs doc | This step is not mandatory.
+--------------------+ 
          |
+--------------------+ 
|      closed        | No work left is required at this stage.
+--------------------+

• feature : new feature or functionnal changement asked
• trivial : not use
• text : label, color, graphic modifications
• tweak : not use
• minor : workaround exist or minor bug
• major : important feature KO
• crash : bug ⇒ data lost
• block : block a lot of features

The bugtracker contains the following public projects:

This project contains all features relative to the TOS Studio.

• repository,
• job editor,
• context,
• generated code,
• export scripts & items
• etc.

This project contains all features relative to the TIS Studio and that are not in TOS Studio.

• Joblets,
• Distant run
• autodocumentation,
• Change data capture,
• etc.

For example, a problem with the tMysqlOutput should be added in the TOS Studio, even if the problem occurs in a TIS Studio.

This project contains all features relative to the AMC stand alone product or the AMC perspective in TIS Studio.

All server-side TIS products:

• Web app,
• Command line,
• Job server.

This project contains all features relative to the TOP product.

This project contains all features relative to the TDQ product and that are not in TOP.

Be sure to define your bug report or feature in the relative project to allow us to treat it as quickly as possible.

In Talend Open Studio, Talend Open Profiler and other Eclipse based studios the error log can be exported from the “Error Log” view. To open this view, select the menu “Window > Show view > General > Error Log”. Then use the “Export” button of the Error Log view.

By default an issue is public. The goal is to share solutions with Talend community and make obvious bugs are known and solutions are being found.

If your issue contains any private information, do not hesitate to change the “View Status” to “private”.

Warning: a file attached to the issue cannot be set private individually. You have to set the whole issue as private if you have a private document to attach.

When a bug appears in several versions of a product, the Talend team will set the “target version” to the lowest supported version in which the bug appear.

Example: a bug appears in version 3.1.3, 3.2.1, 4.0.2 and 4.1.0. Talend supports the last 3 releases. In this example, if the 4.1.0 is the last version of the products, then Talend supports the 4.1x, 4.0.x and 3.2.x version but not the 3.1.x. The target version will be set to 3.2.4 (assuming that the 3.2.3 already exists and 3.2.4 is not released yet).

When this bug is fixed, the “fixed in version” field is set to the lowest supported version number: 3.2.4 in this example. Of course, the correction is backported to all supported branches (here 4.0 and 4.1).