Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Platform UI Bugs"

(Accepting Patches From The Community)
(Accepting Patches From The Community: Link to the email in question.)
Line 53: Line 53:
 
# mark the bug as fixed and include in the comment "patch applied"
 
# mark the bug as fixed and include in the comment "patch applied"
  
For more details, see [[Development_Resources/Automatic_IP_Log#Contributors]]
+
For more details, see [[Development Resources/Automatic IP Log#Contributors]].
[[Category:Platform UI]].
+
  
John Arthorne had said the following in an email to the community:
+
John Arthorne had said the following in an [http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08253.html 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 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.''
 
''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.''
 +
 +
[[Category:Platform UI]]

Revision as of 22:57, 19 August 2008

Template:Platform UI

Logging

We use component area tags in square brackets in the bug Summary. These tags denote the area in Platform UI where the bug exists. The tags facilitate querying of all bugs in a certain component category. Different committers own different components.

When logging a bug, you can use these tags to help the person triaging to better understand the bug and to know who to assign the bug to.

Helpful link: How to Report a Deadlock

Triage

  • one member of the team acts as "triage monkey"
  • "triage monkey" assigns bug to the appropriate owner and tags it with the appropriate component area
  • you can use the greasemonkey script to automate component and ownership assignment
  • owner examines bug and applies categorization

Categorization

Real

The bug is real and is one we intend on fixing in the milestone specific. 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.

  1. examine the patch and apply if it's deemed acceptable
  2. ensure that the bug is assigned to yourself
  3. ensure that the bug has the "contributed" keyword and mark the attachment as "iplog"
  4. 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.

Back to the top