Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Sirius/Bugzilla"
(→Interesting Queries) |
|||
| Line 1: | Line 1: | ||
This page documents how the Sirius team handles their Bugzilla issues. | This page documents how the Sirius team handles their Bugzilla issues. | ||
| − | == | + | == Useful Queries == |
* [https://bugs.eclipse.org/bugs/buglist.cgi?classification=Modeling&product=Sirius&query_format=advanced All Sirius-related issues] | * [https://bugs.eclipse.org/bugs/buglist.cgi?classification=Modeling&product=Sirius&query_format=advanced All Sirius-related issues] | ||
| Line 11: | Line 11: | ||
* [https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Modeling&email1=%40obeo.fr&emailreporter1=1&emailtype1=notsubstring&product=Sirius&query_format=advanced Community issues]: issues reported by people outside of the Sirius development team. | * [https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Modeling&email1=%40obeo.fr&emailreporter1=1&emailtype1=notsubstring&product=Sirius&query_format=advanced Community issues]: issues reported by people outside of the Sirius development team. | ||
* [https://bugs.eclipse.org/bugs/buglist.cgi?classification=Modeling&product=Sirius&query_format=advanced&status_whiteboard=backport&status_whiteboard_type=allwordssubstr Backport candidates]: issues we may want to backport to maintenance branches. | * [https://bugs.eclipse.org/bugs/buglist.cgi?classification=Modeling&product=Sirius&query_format=advanced&status_whiteboard=backport&status_whiteboard_type=allwordssubstr Backport candidates]: issues we may want to backport to maintenance branches. | ||
| + | |||
| + | == Performance Issues == | ||
| + | |||
| + | When reporting a performance issue, add the <code>performance</code> 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. | ||
[[Category:Sirius]] | [[Category:Sirius]] | ||
Revision as of 07:55, 27 October 2014
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
performancekeyword. - 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.