This page documents how the Sirius team handles their Bugzilla issues.
- All Sirius-related issues
- All opened Sirius issues
- Issues waiting to be triaged
- Unplanned issues, i.e. open issues which are not yet planned for a specific release.
- Performance-related issues, marked with the
- Automatic bug reports which may concern Sirius. This is only available to Eclipse Commiters. See also this version.
- Community issues: issues reported by people outside of the Sirius development team.
- Backport candidates: issues we may want to backport to maintenance branches.
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.
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.