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.
Platform UI/Bug Triage
Contents
Helpful links
- bug overview (all bugs in Platform UI and IDE, by owners, severities and priorities)
- Greasemonkey script
- Component Areas - We use component area tags in square brackets in the bug summary. The tags facilitate querying of all bugs in a certain component category. For each component area, there is one committer who watches the bugs in that component area. Historically, the committer would be assigned as the owner of the bug. Over time, we will move all bugs that are not worked on or planned to the account platform-ui-triaged@eclipse.org and use the "QA Contact" field instead for purposes of watching the bugs.
- Why we changed our bug triage process in February 2009
- How to Report a Deadlock
- Bug Triage Tips
The New Bug Triage Process in Detail
Platform UI/Bug Triage Change 2009 - the problem description and transition information
This is how our bug triage process looks like:
Incoming bugs are triaged by a full-time committer on a rotating basis. The goal is to have an empty inbox, no bug should stay in the inbox for longer than a few days.
Incoming bugs: To do triage, we use the Greasemonkey script (with buttons for all component areas). Clicking on a button will
- Prefix the bug description with [ComponentArea].
- Set the "QA contact" field to the person responsible for watching bugs in the identified component.
- Assign the bug to platform-ui-triaged@eclipse.org (separate account from platform-ui-inbox).
As part of the triage, we need to make sure that the bug contains enough information, and that the "severity" is set to a value that makes sense. Enhancement request need to be marked as such, and the same is true for blocker/critical bugs.
When a person is assigned as the QA contact for a bug:
- Double-check that there is enough information in the bug, and that the severity is accurate.
- If it is a blocker or critical bug (e.g. loss of data, crash), it needs to be fixed as soon as possible. If you are not able to fix the bug yourself, assign it to someone else who is.
- If it is a regression, it needs to be fixed during the current development cycle, or potentially in a maintenance stream as well. Schedule the bug accordingly, or assign it to someone else who has time to work on it.
- For all other bugs, try to stay "on top" of the bugs you are watching in the sense that you can produce a rough prioritization of the bugs in a component area. Something like: "if we had the time to fix these ten bugs, our code would be in much better shape".
When a new comment is made on a bug you are watching:
- Respond on the bug if necessary.
- Adjust prioritization if necessary.
Categorization
Real
The bug is real and is one we intend on fixing in the milestone specified. Although we cannot promise to address it in this timeframe, this is our intention.
Status: ASSIGNED Milestone: something reasonable
Real No Time
The bug is real but we do not have the time to address it. We would entertain patches for these issues.
Status: ASSIGNED Milestone: no milestone Keywords: helpwanted if appropriate
Real Not A Priority
The bug is real but we do not feel it's that important. We would entertain patches for these issues.
Status: ASSIGNED Keywords: helpwanted if appropriate Priority: P5
Not Real
The bug is not valid. We will not address it further. If it's a bug regarding established behaviour we do not wish to change mark as WONTFIX. If it's simply not a problem as described in the report use INVALID.
Status: WONTFIX or INVALID
Accepting Patches From The Community
The following steps should be taken when committing patches from members of the community who are not committers on the Eclipse top-level project.
- examine the patch and apply if it's deemed acceptable
- ensure that the bug is assigned to yourself
- ensure that the bug has the "contributed" keyword and mark the attachment as "iplog"
- mark the bug as fixed and include in the comment "patch applied"
For more details, see Development Resources/Automatic IP Log#Contributors.
John Arthorne had said the following in an email to the community:
There has been some confusion about the new "iplog" flag so I should clarify. The "iplog" flag should be set on the *attachment* that contains the contribution. This is done by clicking "Details" next to the attachment, and then setting the "iplog" flag for that attachment. If there are multiple attachments being contributed, add the flag for each applicable attachment. This allows the system to automatically harvest data about the size of the contribution, who contributed it (the person who added the attachment), and the committer who processed the contribution (the person who set the "iplog+" flag).
There is also an "iplog" flag for the entire bug report next to the "review" and "pmc_approved" flags. This flag should only be used if the contribution is not in the form of an attachment. For example, you can use this if the contributor added code or pseudo-code directly in the comment field. The simple solution in this case is to ask the contributor to attach a proper patch so it can be flagged. If this is not possible or the contributor doesn't respond, you can resort to setting the global "iplog" flag on the bug itself. What this flag does is flag every non-committer who added a comment to the bug as contributors. If there are comments in the same bug that are not part of the contribution, they then need to be excluded manually by editing the project IP log. See the IP log documentation for more details.