Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Sirius/Bugzilla
This page documents how the Sirius team handles their Bugzilla issues.
Useful Queries
- 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
performance
keyword. - Automatic bug reports which may concern Sirius. This is only available to Eclipse Commiters.
- Community issues: issues reported by people outside of the Sirius development team.
- Backport candidates: issues we may want to backport to maintenance branches.
Performance Issues
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.
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.