Skip to main content
Jump to: navigation, search


This page documents how the Sirius team handles their Bugzilla issues.

Useful Queries

Performance Issues

Reporters: When reporting a performance issue, add the performance keyword to the issue, and include actual measures (even approximate) of both the resource usage (time, memory...) you experienced and the amount of data in your use case. Even better, attach a representative use case. These information are critical for the Sirius team to properly prioritize the issue and reproduce it.

Contributors: When working on such a performance issue, make sure you have a repeatable use case attached in the bug (created one if the reporter did not provide one), and always provide before/after measures with and without your proposed patches. A performance patch which does not include any repeatable proof that it actually improved the system's performance in a measurable and significant way will not be considered for merging.

Backport Candidates

Contributors: If you fix an issue on master for the next release and you believe it should be backported to maintenance version(s), add the backport tag in the Whiteboard field in the issue. The Backport candidates query above can be used to identify and review all such candidates. Once a decision has been taken to backport the fix or not, the tag should be removed (if the decision is to backport, a clone issue targetting the appropriate maintenance branche(s) will be created). Remember that only fixes for important issues, with no API changes, and for which we are absolutely sure there is no risk of regression can be candidates.

Back to the top