Examine individual changes
From Gentoo Wiki
This page allows you to examine the variables generated by the Abuse Filter for an individual change, and test it against filters.
Variables generated for this change
| Variable | Value |
|---|---|
Edit count of the user (user_editcount) | 2756 |
Name of the user account (user_name) | 'MGorny' |
Age of the user account (user_age) | 338289966 |
Page ID (page_id) | 33533 |
Page namespace (page_namespace) | 510 |
Page title (without namespace) (page_title) | 'Bug-wranglers' |
Full page title (page_prefixedtitle) | 'Project:Bug-wranglers' |
Action (action) | 'edit' |
Edit summary/reason (summary) | 'polynomial-c is retiring' |
Old content model (old_content_model) | 'wikitext' |
New content model (new_content_model) | 'wikitext' |
Old page wikitext, before the edit (old_wikitext) | '{{Project
|Name=Bug Wranglers
|Description=Bug Wranglers elaborate how to proceed with bugs on the Gentoo bug tracker.
|Email=bug-wranglers@gentoo.org
|IRC=#gentoo-bugs
|ParentProject=Project:Quality Assurance
|PropagatesMembers=No
|LeadElectionDate=2020/05/02
|Members={{Project Member
|Developer=User:Polynomial-C
|IsLead=No
}}{{Project Member
|Developer=User:Jstein
|Role=team leader
|IsLead=Yes
}}
}}
{{DISPLAYTITLE:Bug Wranglers}}
The Gentoo Bug Wranglers Project elaborates how to proceed with bugs on the [https://bugs.gentoo.org/ Gentoo bug tracker].
Our goal is that bugs get fixed as efficiently as possible.
__TOC__
== Bug wrangling ==
=== Assessing bug reports ===
Bug reports that say something isn't working or compiling '''without a comprehensive analysis of the causes''', should contain at least the output of {{c|emerge --info}} as well as a thorough description of the problem, including error output (or expected versus actual output), the command that led to the error or faulty output, and concise steps explaining how to reproduce the issue. It is customary to only assign a bug report once these requirements have been fulfilled. If the reporter hasn't fulfilled these requirements, the bug report should stay assigned to bug-wranglers, and a full build log should be requested from the reporter.
Bug reports that refer to a single or a few (similar) packages should detail the '''package atom(s)''' as completely as possible (at least the CATEGORY/PKG(s)) at the start of the <code>Summary</code>. If the ebuild is from an overlay, the name of the overlay should be prefixed at the start in square brackets. The atom should include a version only when other versions do not exhibit the bug.
{{CodeBox|title=standard format of the Summary|1=[name overlay] CATEGORY/PKG(-version(-revision)) - {problem description}/{action}
}}
Bug reports about '''eclasses''' should list the full eclass filename in the <code>Summary</code> instead of an atom. Bug reports about '''profiles''' should list the full profile name in the <code>Summary</code> instead of an atom.
=== Acquiring more information ===
Bug reports can quickly get messy from comments and attachments that may or may not be appropriate to the bug being reported. Sometimes, it is necessary to request that no more information is added. In general, be gentle in your verbal assessment of a bug report. Even if you are quite certain that it's going to be resolved as <code>INVALID</code>, you should treat the reporter '''courteously'''.
* If you find that a reported problem arose because '''the reporter lacks certain skills''' or knowledge, then provide the so-called 'obvious' solution to the problem and suggest that he might try that. It is unnecessary to explain that you consider the reported problem not to be a bug. Just resolve the bug with a <code>TEST-REQUEST</code> (instead of as <code>INVALID</code> ) and suggest that the reporter tests the solution you provide, and that he reopens the bug only when that doesn't solve the problem.
* Assume that the reporter can help but may not know how. In practice, that means you provide the '''commands that produce the information you require'''. Do so even if the means to that end seem trivial, like asking for {{c|emerge --info}} or {{c|emerge -vp cat/pkg}}.
* If `emerge --info' is missing, ask to provide it and to reopen the ticket afterwards. Mark the bug as <code>CLOSED/NEEDINFO</code> and wait.
* Bug reports should be concise, as all too quickly they bog down and can be best understood after reading, say, nothing but comment #1, #2 and #7, ignoring all 40 intermediate and later comments which are the me-toos and not-mes (including lots of {{c|emerge --info}} and/or hardware collection lists that may or may not be relevant). '''When enough information has been presented''' to 'make a case', it's appropriate to say so.
=== Assigning bug reports ===
* Bug reports requesting '''version bumps''' should be assigned to the appropriate maintainers directly. Also check the description of the bug for references to security bugs, in which case the bug report should be assigned to {{Mail|security@gentoo.org}} immediately, using product "Gentoo Security" and component "Vulnerabilities", with the maintainers CC'd.
* If a bug report pertains to a specific '''package''', then you enter the package's directory in your copy of the [https://gitweb.gentoo.org/repo/gentoo.git/ gentoo git repository] (or perhaps the online version which should always be more or less up to date) and read the {{Path|metadata.xml}} file you find there. When {{Path|metadata.xml}} lists a single maintainer, then you assign the bug to that maintainer. When the file lists multiple entries, then you assign the bug to the first <code><maintainer></code>, and CC the other <code><maintainer></code>(s). If you find that {{Path|metadata.xml}} lists inappropriate and/or confusing contact information, then make a note of that in a comment on the bug report and assign/CC the bug report as well as you can.
* Bug reports about packages in '''overlays''' should be assigned to the <code><owner></code> tag in {{Path|[https://api.gentoo.org/overlays/repositories.xml repositories.xml]}}. Some of these overlays want to get their bugs tracked elsewhere, and explicitly state this in their <code><description></code> tags.
* When a bug report calls attention to '''multiple packages''', then things get slightly more complicated. When the listed packages do not belong to the same maintainer or team, for instance when a library upgrade causes several packages to fail to emerge or run, then you should ask the bug reporter to file separate bugs assigned to each set of packages' maintainer(s), and make those bug reports block the original bug report, which then becomes a '''tracker bug''' (denoted by the <code>Tracker</code> keyword.
* Assign bug reports about '''eclasses''' to the eclass maintainer mentioned in the [https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass .eclass file].
* A '''keyword request''' should be assigned to the package's maintainer and CC'd to the appropriate arch team(s). The report's <code>Keywords</code> field should contain the <code>KEYWORDREQ</code> keyword.
* A '''stabilization request''' should be handled by the package's maintainer, so you should not CC arch teams in your role as bug wrangler, nor set the <code>STABLEREQ</code> keyword in the <code>Keywords</code> field. Unless the package is maintainer-needed, then you should add arches and set the Keyword field if the bug makes sense.
* Bug reports that concern '''profiles''' should be assigned to [mailto:qa@gentoo.org qa@gentoo.org] with [mailto:release@gentoo.org release@gentoo.org] CC'd. Exceptions are profiles that are obviously maintained by some project, like hardened, selinux, prefix, etc. Those get assigned to the maintaining project.
* Bug reports that relate to issues other than the portage tree, like problems with Gentoo's Bugzilla, Gentoo infrastructure, mirrors or staffing matters (devrel, userrel and so on) are usually easier to assign. The <code>Product</code> and <code>Component</code> fields of each bug should help you (re)assign these reports appropriately.
* Bugs about '''cross compilation''' should be assigned to [mailto:cross@gentoo.org cross@gentoo.org]
* Bug reports that '''include patches''' or other solutions can usually be assigned directly to the maintainers.
* If a acct-user related bug is related to a specific package, add both to the summary as in {{Bug|729322}} and assign to the package maintainer.
* Assign bugs which occur on a specific '''architecture''' only (arm, arm64, ppc, ...) to the maintainer of the package. The maintainer of the package can ping the arch teams on IRC in order to solve the bug together.
'''Please contact Bug-wranglers, if we need adjustments on the above agreements.'''
== Participating ==
The best approach to bug wrangling is to really '''get involved''' with individual bug reports.
* All users with [[editbugs privilege]] on Bugzilla are invited to assign bug reports
* Working on bug reports is an exhausting job. Don't try to do '''everything'''.
* Some bug reports make your blood boil. Ignore them and let someone else handle them.
* Be '''friendly''', but '''not chatty'''.
* Use '''precise wording''' that leads to precise answers and a solution.
* You can CC yourself to monitor, if you assigned a bug report properly or when you requested information. You can set '''auto CC''' in your bugzilla preferences, if you like. You can always un-CC again.
* '''Avoid full quotes'''.
* Help to guide to satisfactory '''solutions'''.
=== Resources ===
* [[:Template:Bug|Bug Template for the Wiki pages]]
* [https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&list_id=4592980&namedcmd=Bug%20Wranglers&remaction=run&sharer_id=46764 New unassigned bug tickets] which are still assigned to Bugwranglers (also available in your bugzilla Preferences -> Saved Searches)
* [https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=active%20TRACKER&sharer_id=85842 Active Tracker Bug Tickets] (activity within the last 180 days)
* A [https://github.com/mgorny/bug-assign-user-js JavaScript plugin] for [https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/ greasemonkey] to assign bugs fast and easy.
* [https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&list_id=5172112&namedcmd=m-n%20PATCH&remaction=run Bugs assigned to '''maintainer-needed''' with a '''PATCH''']
=== History ===
The project was set up after the de-facto resignation of long time ''Main Bug Wrangler'' Jakub Moc, when it turned out we required a division of labor to get all bugs properly assigned within an acceptable time frame (from the moment of a bug report's creation to its proper assignment). For his years of relentless bug wrangling, this project both owes him its gratitude and earns its existence.
{{Migrated|originalauthors=jer}}' |
New page wikitext, after the edit (new_wikitext) | '{{Project
|Name=Bug Wranglers
|Description=Bug Wranglers elaborate how to proceed with bugs on the Gentoo bug tracker.
|Email=bug-wranglers@gentoo.org
|Packages=No
|IRC=#gentoo-bugs
|ParentProject=Project:Quality Assurance
|PropagatesMembers=No
|LeadElectionDate=2020-05-02
|Members={{Project Member
|Developer=User:Jstein
|Role=team leader
|IsLead=Yes
}}
}}
{{DISPLAYTITLE:Bug Wranglers}}
The Gentoo Bug Wranglers Project elaborates how to proceed with bugs on the [https://bugs.gentoo.org/ Gentoo bug tracker].
Our goal is that bugs get fixed as efficiently as possible.
__TOC__
== Bug wrangling ==
=== Assessing bug reports ===
Bug reports that say something isn't working or compiling '''without a comprehensive analysis of the causes''', should contain at least the output of {{c|emerge --info}} as well as a thorough description of the problem, including error output (or expected versus actual output), the command that led to the error or faulty output, and concise steps explaining how to reproduce the issue. It is customary to only assign a bug report once these requirements have been fulfilled. If the reporter hasn't fulfilled these requirements, the bug report should stay assigned to bug-wranglers, and a full build log should be requested from the reporter.
Bug reports that refer to a single or a few (similar) packages should detail the '''package atom(s)''' as completely as possible (at least the CATEGORY/PKG(s)) at the start of the <code>Summary</code>. If the ebuild is from an overlay, the name of the overlay should be prefixed at the start in square brackets. The atom should include a version only when other versions do not exhibit the bug.
{{CodeBox|title=standard format of the Summary|1=[name overlay] CATEGORY/PKG(-version(-revision)) - {problem description}/{action}
}}
Bug reports about '''eclasses''' should list the full eclass filename in the <code>Summary</code> instead of an atom. Bug reports about '''profiles''' should list the full profile name in the <code>Summary</code> instead of an atom.
=== Acquiring more information ===
Bug reports can quickly get messy from comments and attachments that may or may not be appropriate to the bug being reported. Sometimes, it is necessary to request that no more information is added. In general, be gentle in your verbal assessment of a bug report. Even if you are quite certain that it's going to be resolved as <code>INVALID</code>, you should treat the reporter '''courteously'''.
* If you find that a reported problem arose because '''the reporter lacks certain skills''' or knowledge, then provide the so-called 'obvious' solution to the problem and suggest that he might try that. It is unnecessary to explain that you consider the reported problem not to be a bug. Just resolve the bug with a <code>TEST-REQUEST</code> (instead of as <code>INVALID</code> ) and suggest that the reporter tests the solution you provide, and that he reopens the bug only when that doesn't solve the problem.
* Assume that the reporter can help but may not know how. In practice, that means you provide the '''commands that produce the information you require'''. Do so even if the means to that end seem trivial, like asking for {{c|emerge --info}} or {{c|emerge -vp cat/pkg}}.
* If `emerge --info' is missing, ask to provide it and to reopen the ticket afterwards. Mark the bug as <code>CLOSED/NEEDINFO</code> and wait.
* Bug reports should be concise, as all too quickly they bog down and can be best understood after reading, say, nothing but comment #1, #2 and #7, ignoring all 40 intermediate and later comments which are the me-toos and not-mes (including lots of {{c|emerge --info}} and/or hardware collection lists that may or may not be relevant). '''When enough information has been presented''' to 'make a case', it's appropriate to say so.
=== Assigning bug reports ===
* Bug reports requesting '''version bumps''' should be assigned to the appropriate maintainers directly. Also check the description of the bug for references to security bugs, in which case the bug report should be assigned to {{Mail|security@gentoo.org}} immediately, using product "Gentoo Security" and component "Vulnerabilities", with the maintainers CC'd.
* If a bug report pertains to a specific '''package''', then you enter the package's directory in your copy of the [https://gitweb.gentoo.org/repo/gentoo.git/ gentoo git repository] (or perhaps the online version which should always be more or less up to date) and read the {{Path|metadata.xml}} file you find there. When {{Path|metadata.xml}} lists a single maintainer, then you assign the bug to that maintainer. When the file lists multiple entries, then you assign the bug to the first <code><maintainer></code>, and CC the other <code><maintainer></code>(s). If you find that {{Path|metadata.xml}} lists inappropriate and/or confusing contact information, then make a note of that in a comment on the bug report and assign/CC the bug report as well as you can.
* Bug reports about packages in '''overlays''' should be assigned to the <code><owner></code> tag in {{Path|[https://api.gentoo.org/overlays/repositories.xml repositories.xml]}}. Some of these overlays want to get their bugs tracked elsewhere, and explicitly state this in their <code><description></code> tags.
* When a bug report calls attention to '''multiple packages''', then things get slightly more complicated. When the listed packages do not belong to the same maintainer or team, for instance when a library upgrade causes several packages to fail to emerge or run, then you should ask the bug reporter to file separate bugs assigned to each set of packages' maintainer(s), and make those bug reports block the original bug report, which then becomes a '''tracker bug''' (denoted by the <code>Tracker</code> keyword.
* Assign bug reports about '''eclasses''' to the eclass maintainer mentioned in the [https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass .eclass file].
* A '''keyword request''' should be assigned to the package's maintainer and CC'd to the appropriate arch team(s). The report's <code>Keywords</code> field should contain the <code>KEYWORDREQ</code> keyword.
* A '''stabilization request''' should be handled by the package's maintainer, so you should not CC arch teams in your role as bug wrangler, nor set the <code>STABLEREQ</code> keyword in the <code>Keywords</code> field. Unless the package is maintainer-needed, then you should add arches and set the Keyword field if the bug makes sense.
* Bug reports that concern '''profiles''' should be assigned to [mailto:qa@gentoo.org qa@gentoo.org] with [mailto:release@gentoo.org release@gentoo.org] CC'd. Exceptions are profiles that are obviously maintained by some project, like hardened, selinux, prefix, etc. Those get assigned to the maintaining project.
* Bug reports that relate to issues other than the portage tree, like problems with Gentoo's Bugzilla, Gentoo infrastructure, mirrors or staffing matters (devrel, userrel and so on) are usually easier to assign. The <code>Product</code> and <code>Component</code> fields of each bug should help you (re)assign these reports appropriately.
* Bugs about '''cross compilation''' should be assigned to [mailto:cross@gentoo.org cross@gentoo.org]
* Bug reports that '''include patches''' or other solutions can usually be assigned directly to the maintainers.
* If a acct-user related bug is related to a specific package, add both to the summary as in {{Bug|729322}} and assign to the package maintainer.
* Assign bugs which occur on a specific '''architecture''' only (arm, arm64, ppc, ...) to the maintainer of the package. The maintainer of the package can ping the arch teams on IRC in order to solve the bug together.
'''Please contact Bug-wranglers, if we need adjustments on the above agreements.'''
== Participating ==
The best approach to bug wrangling is to really '''get involved''' with individual bug reports.
* All users with [[editbugs privilege]] on Bugzilla are invited to assign bug reports
* Working on bug reports is an exhausting job. Don't try to do '''everything'''.
* Some bug reports make your blood boil. Ignore them and let someone else handle them.
* Be '''friendly''', but '''not chatty'''.
* Use '''precise wording''' that leads to precise answers and a solution.
* You can CC yourself to monitor, if you assigned a bug report properly or when you requested information. You can set '''auto CC''' in your bugzilla preferences, if you like. You can always un-CC again.
* '''Avoid full quotes'''.
* Help to guide to satisfactory '''solutions'''.
=== Resources ===
* [[:Template:Bug|Bug Template for the Wiki pages]]
* [https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&list_id=4592980&namedcmd=Bug%20Wranglers&remaction=run&sharer_id=46764 New unassigned bug tickets] which are still assigned to Bugwranglers (also available in your bugzilla Preferences -> Saved Searches)
* [https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=active%20TRACKER&sharer_id=85842 Active Tracker Bug Tickets] (activity within the last 180 days)
* A [https://github.com/mgorny/bug-assign-user-js JavaScript plugin] for [https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/ greasemonkey] to assign bugs fast and easy.
* [https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&list_id=5172112&namedcmd=m-n%20PATCH&remaction=run Bugs assigned to '''maintainer-needed''' with a '''PATCH''']
=== History ===
The project was set up after the de-facto resignation of long time ''Main Bug Wrangler'' Jakub Moc, when it turned out we required a division of labor to get all bugs properly assigned within an acceptable time frame (from the moment of a bug report's creation to its proper assignment). For his years of relentless bug wrangling, this project both owes him its gratitude and earns its existence.
{{Migrated|originalauthors=jer}}' |
Unified diff of changes made by edit (edit_diff) | '@@ -3,12 +3,10 @@
|Description=Bug Wranglers elaborate how to proceed with bugs on the Gentoo bug tracker.
|Email=bug-wranglers@gentoo.org
+|Packages=No
|IRC=#gentoo-bugs
|ParentProject=Project:Quality Assurance
|PropagatesMembers=No
-|LeadElectionDate=2020/05/02
+|LeadElectionDate=2020-05-02
|Members={{Project Member
-|Developer=User:Polynomial-C
-|IsLead=No
-}}{{Project Member
|Developer=User:Jstein
|Role=team leader
' |
Old page size (old_size) | 9959 |
Lines added in edit (added_lines) | [
0 => '|Packages=No',
1 => '|LeadElectionDate=2020-05-02'
] |
Lines removed in edit (removed_lines) | [
0 => '|LeadElectionDate=2020/05/02',
1 => '|Developer=User:Polynomial-C',
2 => '|IsLead=No',
3 => '}}{{Project Member'
] |
New page text, stripped of any markup (new_text) | '
Bug Wranglers
Description
Bug Wranglers elaborate how to proceed with bugs on the Gentoo bug tracker.
Project email
bug-wranglers@gentoo.org
IRC channel
#gentoo-bugs (webchat)
Lead(s)
Jonas Stein
(jstein)team leader Last elected: 2020-05-02
Member(s)
Lars Wendler
(Polynomial-C)
Subproject(s)(and inherited member(s))
(none)
Parent Project
Quality Assurance
Project listing
The Gentoo Bug Wranglers Project elaborates how to proceed with bugs on the Gentoo bug tracker.
Our goal is that bugs get fixed as efficiently as possible.
Contents
1 Bug wrangling
1.1 Assessing bug reports
1.2 Acquiring more information
1.3 Assigning bug reports
2 Participating
2.1 Resources
2.2 History
Bug wrangling[edit | edit source]
Assessing bug reports[edit | edit source]
Bug reports that say something isn't working or compiling without a comprehensive analysis of the causes, should contain at least the output of emerge --info as well as a thorough description of the problem, including error output (or expected versus actual output), the command that led to the error or faulty output, and concise steps explaining how to reproduce the issue. It is customary to only assign a bug report once these requirements have been fulfilled. If the reporter hasn't fulfilled these requirements, the bug report should stay assigned to bug-wranglers, and a full build log should be requested from the reporter.
Bug reports that refer to a single or a few (similar) packages should detail the package atom(s) as completely as possible (at least the CATEGORY/PKG(s)) at the start of the Summary. If the ebuild is from an overlay, the name of the overlay should be prefixed at the start in square brackets. The atom should include a version only when other versions do not exhibit the bug.
CODE standard format of the Summary[name overlay] CATEGORY/PKG(-version(-revision)) - {problem description}/{action}
Bug reports about eclasses should list the full eclass filename in the Summary instead of an atom. Bug reports about profiles should list the full profile name in the Summary instead of an atom.
Acquiring more information[edit | edit source]
Bug reports can quickly get messy from comments and attachments that may or may not be appropriate to the bug being reported. Sometimes, it is necessary to request that no more information is added. In general, be gentle in your verbal assessment of a bug report. Even if you are quite certain that it's going to be resolved as INVALID, you should treat the reporter courteously.
If you find that a reported problem arose because the reporter lacks certain skills or knowledge, then provide the so-called 'obvious' solution to the problem and suggest that he might try that. It is unnecessary to explain that you consider the reported problem not to be a bug. Just resolve the bug with a TEST-REQUEST (instead of as INVALID ) and suggest that the reporter tests the solution you provide, and that he reopens the bug only when that doesn't solve the problem.
Assume that the reporter can help but may not know how. In practice, that means you provide the commands that produce the information you require. Do so even if the means to that end seem trivial, like asking for emerge --info or emerge -vp cat/pkg.
If `emerge --info' is missing, ask to provide it and to reopen the ticket afterwards. Mark the bug as CLOSED/NEEDINFO and wait.
Bug reports should be concise, as all too quickly they bog down and can be best understood after reading, say, nothing but comment #1, #2 and #7, ignoring all 40 intermediate and later comments which are the me-toos and not-mes (including lots of emerge --info and/or hardware collection lists that may or may not be relevant). When enough information has been presented to 'make a case', it's appropriate to say so.
Assigning bug reports[edit | edit source]
Bug reports requesting version bumps should be assigned to the appropriate maintainers directly. Also check the description of the bug for references to security bugs, in which case the bug report should be assigned to security@gentoo.org immediately, using product "Gentoo Security" and component "Vulnerabilities", with the maintainers CC'd.
If a bug report pertains to a specific package, then you enter the package's directory in your copy of the gentoo git repository (or perhaps the online version which should always be more or less up to date) and read the metadata.xml file you find there. When metadata.xml lists a single maintainer, then you assign the bug to that maintainer. When the file lists multiple entries, then you assign the bug to the first <maintainer>, and CC the other <maintainer>(s). If you find that metadata.xml lists inappropriate and/or confusing contact information, then make a note of that in a comment on the bug report and assign/CC the bug report as well as you can.
Bug reports about packages in overlays should be assigned to the <owner> tag in repositories.xml. Some of these overlays want to get their bugs tracked elsewhere, and explicitly state this in their <description> tags.
When a bug report calls attention to multiple packages, then things get slightly more complicated. When the listed packages do not belong to the same maintainer or team, for instance when a library upgrade causes several packages to fail to emerge or run, then you should ask the bug reporter to file separate bugs assigned to each set of packages' maintainer(s), and make those bug reports block the original bug report, which then becomes a tracker bug (denoted by the Tracker keyword.
Assign bug reports about eclasses to the eclass maintainer mentioned in the .eclass file.
A keyword request should be assigned to the package's maintainer and CC'd to the appropriate arch team(s). The report's Keywords field should contain the KEYWORDREQ keyword.
A stabilization request should be handled by the package's maintainer, so you should not CC arch teams in your role as bug wrangler, nor set the STABLEREQ keyword in the Keywords field. Unless the package is maintainer-needed, then you should add arches and set the Keyword field if the bug makes sense.
Bug reports that concern profiles should be assigned to qa@gentoo.org with release@gentoo.org CC'd. Exceptions are profiles that are obviously maintained by some project, like hardened, selinux, prefix, etc. Those get assigned to the maintaining project.
Bug reports that relate to issues other than the portage tree, like problems with Gentoo's Bugzilla, Gentoo infrastructure, mirrors or staffing matters (devrel, userrel and so on) are usually easier to assign. The Product and Component fields of each bug should help you (re)assign these reports appropriately.
Bugs about cross compilation should be assigned to cross@gentoo.org
Bug reports that include patches or other solutions can usually be assigned directly to the maintainers.
If a acct-user related bug is related to a specific package, add both to the summary as in bug #729322 and assign to the package maintainer.
Assign bugs which occur on a specific architecture only (arm, arm64, ppc, ...) to the maintainer of the package. The maintainer of the package can ping the arch teams on IRC in order to solve the bug together.
Please contact Bug-wranglers, if we need adjustments on the above agreements.
Participating[edit | edit source]
The best approach to bug wrangling is to really get involved with individual bug reports.
All users with editbugs privilege on Bugzilla are invited to assign bug reports
Working on bug reports is an exhausting job. Don't try to do everything.
Some bug reports make your blood boil. Ignore them and let someone else handle them.
Be friendly, but not chatty.
Use precise wording that leads to precise answers and a solution.
You can CC yourself to monitor, if you assigned a bug report properly or when you requested information. You can set auto CC in your bugzilla preferences, if you like. You can always un-CC again.
Avoid full quotes.
Help to guide to satisfactory solutions.
Resources[edit | edit source]
Bug Template for the Wiki pages
New unassigned bug tickets which are still assigned to Bugwranglers (also available in your bugzilla Preferences -> Saved Searches)
Active Tracker Bug Tickets (activity within the last 180 days)
A JavaScript plugin for greasemonkey to assign bugs fast and easy.
Bugs assigned to maintainer-needed with a PATCH
History[edit | edit source]
The project was set up after the de-facto resignation of long time Main Bug Wrangler Jakub Moc, when it turned out we required a division of labor to get all bugs properly assigned within an acceptable time frame (from the moment of a bug report's creation to its proper assignment). For his years of relentless bug wrangling, this project both owes him its gratitude and earns its existence.
This page is based on a document formerly found on our main website gentoo.org. The following people contributed to the original document: jerThey are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.' |
Parsed HTML source of the new revision (new_html) | '<div class="mw-parser-output"><table class="table table-condensed" style="width: 30em; font-size: 95%; border: 1px solid #ddd; background-color: #f9f9f9; color: black; margin-bottom: 0.5em; margin-left: 1em; padding: 0.2em; float: right; clear: right; text-align:left;">
<tbody><tr>
<th style="text-align: center; background-color:#3E355A; color: white;" colspan="2"><big>Bug Wranglers</big>
</th></tr>
<tr valign="top">
<th>Description
</th>
<td style="text-align: justify;">Bug Wranglers elaborate how to proceed with bugs on the Gentoo bug tracker.
</td></tr>
<tr>
<th><span title="Mails to member(s) listed below.">Project email</span>
</th>
<td><a rel="nofollow" class="external text" href="mailto:bug-wranglers@gentoo.org">bug-wranglers@gentoo.org</a>
</td></tr>
<tr>
<th><span title="The link opens an IRC client to libera.chat IRC channel.">IRC channel</span>
</th>
<td><span style="font-family: monospace; font-size: 95%;"><a rel="nofollow" class="external text" href="ircs://irc.libera.chat/#gentoo-bugs">#gentoo-bugs</a></span> (<span style="font-family: monospace; font-size: 95%;"><a rel="nofollow" class="external text" href="https://web.libera.chat/#gentoo-bugs">webchat</a></span>)
</td></tr>
<tr valign="top">
<th>Lead(s)
</th>
<td><ul><li><a href="/wiki/User:Jstein" title="User:Jstein">Jonas Stein</a>
(jstein)<br /><i>team leader</i></li></ul> <br />Last elected: 2020-05-02
</td></tr>
<tr valign="top">
<th>Member(s)
</th>
<td><ul><li><a href="/wiki/User:Polynomial-C" title="User:Polynomial-C">Lars Wendler</a>
(Polynomial-C)</li></ul>
</td></tr>
<tr valign="top">
<th>Subproject(s)<br /><small style="font-weight: normal;">(and inherited member(s))</small>
</th>
<td>(none)
</td></tr>
<tr>
<th>Parent Project
</th>
<td><a href="/wiki/Project:Quality_Assurance" title="Project:Quality Assurance">Quality Assurance</a>
</td></tr>
<tr>
<td colspan="2" style="border-top: 1px solid #ddd; font-size: smaller; text-align: center;"><a href="/wiki/Project:Gentoo" title="Project:Gentoo">Project listing</a>
</td></tr></tbody></table>
<p><br />
</p><p>The Gentoo Bug Wranglers Project elaborates how to proceed with bugs on the <a rel="nofollow" class="external text" href="https://bugs.gentoo.org/">Gentoo bug tracker</a>.
Our goal is that bugs get fixed as efficiently as possible.
</p>
<div id="toc" class="toc" role="navigation" aria-labelledby="mw-toc-heading"><input type="checkbox" role="button" id="toctogglecheckbox" class="toctogglecheckbox" style="display:none" /><div class="toctitle" lang="en" dir="ltr"><h2 id="mw-toc-heading">Contents</h2><span class="toctogglespan"><label class="toctogglelabel" for="toctogglecheckbox"></label></span></div>
<ul>
<li class="toclevel-1 tocsection-1"><a href="#Bug_wrangling"><span class="tocnumber">1</span> <span class="toctext">Bug wrangling</span></a>
<ul>
<li class="toclevel-2 tocsection-2"><a href="#Assessing_bug_reports"><span class="tocnumber">1.1</span> <span class="toctext">Assessing bug reports</span></a></li>
<li class="toclevel-2 tocsection-3"><a href="#Acquiring_more_information"><span class="tocnumber">1.2</span> <span class="toctext">Acquiring more information</span></a></li>
<li class="toclevel-2 tocsection-4"><a href="#Assigning_bug_reports"><span class="tocnumber">1.3</span> <span class="toctext">Assigning bug reports</span></a></li>
</ul>
</li>
<li class="toclevel-1 tocsection-5"><a href="#Participating"><span class="tocnumber">2</span> <span class="toctext">Participating</span></a>
<ul>
<li class="toclevel-2 tocsection-6"><a href="#Resources"><span class="tocnumber">2.1</span> <span class="toctext">Resources</span></a></li>
<li class="toclevel-2 tocsection-7"><a href="#History"><span class="tocnumber">2.2</span> <span class="toctext">History</span></a></li>
</ul>
</li>
</ul>
</div>
<p><br />
</p>
<h2><span class="mw-headline" id="Bug_wrangling">Bug wrangling</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Bug-wranglers&veaction=edit&section=1" class="mw-editsection-visualeditor" title="Edit section: Bug wrangling">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=Project:Bug-wranglers&action=edit&section=1" title="Edit section: Bug wrangling">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<h3><span class="mw-headline" id="Assessing_bug_reports">Assessing bug reports</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Bug-wranglers&veaction=edit&section=2" class="mw-editsection-visualeditor" title="Edit section: Assessing bug reports">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=Project:Bug-wranglers&action=edit&section=2" title="Edit section: Assessing bug reports">edit source</a><span class="mw-editsection-bracket">]</span></span></h3>
<p>Bug reports that say something isn't working or compiling <b>without a comprehensive analysis of the causes</b>, should contain at least the output of <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">emerge --info</span> as well as a thorough description of the problem, including error output (or expected versus actual output), the command that led to the error or faulty output, and concise steps explaining how to reproduce the issue. It is customary to only assign a bug report once these requirements have been fulfilled. If the reporter hasn't fulfilled these requirements, the bug report should stay assigned to bug-wranglers, and a full build log should be requested from the reporter.
</p><p>Bug reports that refer to a single or a few (similar) packages should detail the <b>package atom(s)</b> as completely as possible (at least the CATEGORY/PKG(s)) at the start of the <code>Summary</code>. If the ebuild is from an overlay, the name of the overlay should be prefixed at the start in square brackets. The atom should include a version only when other versions do not exhibit the bug.
</p>
<div class="gw-box"><div class="box-caption"><span class="label" style="margin-right: .5em; background-color: #204A87">CODE</span> <strong>standard format of the Summary</strong></div><pre class="captioned">[name overlay] CATEGORY/PKG(-version(-revision)) - {problem description}/{action}</pre></div>
<p>Bug reports about <b>eclasses</b> should list the full eclass filename in the <code>Summary</code> instead of an atom. Bug reports about <b>profiles</b> should list the full profile name in the <code>Summary</code> instead of an atom.
</p>
<h3><span class="mw-headline" id="Acquiring_more_information">Acquiring more information</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Bug-wranglers&veaction=edit&section=3" class="mw-editsection-visualeditor" title="Edit section: Acquiring more information">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=Project:Bug-wranglers&action=edit&section=3" title="Edit section: Acquiring more information">edit source</a><span class="mw-editsection-bracket">]</span></span></h3>
<p>Bug reports can quickly get messy from comments and attachments that may or may not be appropriate to the bug being reported. Sometimes, it is necessary to request that no more information is added. In general, be gentle in your verbal assessment of a bug report. Even if you are quite certain that it's going to be resolved as <code>INVALID</code>, you should treat the reporter <b>courteously</b>.
</p>
<ul><li>If you find that a reported problem arose because <b>the reporter lacks certain skills</b> or knowledge, then provide the so-called 'obvious' solution to the problem and suggest that he might try that. It is unnecessary to explain that you consider the reported problem not to be a bug. Just resolve the bug with a <code>TEST-REQUEST</code> (instead of as <code>INVALID</code> ) and suggest that the reporter tests the solution you provide, and that he reopens the bug only when that doesn't solve the problem.</li>
<li>Assume that the reporter can help but may not know how. In practice, that means you provide the <b>commands that produce the information you require</b>. Do so even if the means to that end seem trivial, like asking for <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">emerge --info</span> or <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">emerge -vp cat/pkg</span>.</li>
<li>If `emerge --info' is missing, ask to provide it and to reopen the ticket afterwards. Mark the bug as <code>CLOSED/NEEDINFO</code> and wait.</li>
<li>Bug reports should be concise, as all too quickly they bog down and can be best understood after reading, say, nothing but comment #1, #2 and #7, ignoring all 40 intermediate and later comments which are the me-toos and not-mes (including lots of <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">emerge --info</span> and/or hardware collection lists that may or may not be relevant). <b>When enough information has been presented</b> to 'make a case', it's appropriate to say so.</li></ul>
<h3><span class="mw-headline" id="Assigning_bug_reports">Assigning bug reports</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Bug-wranglers&veaction=edit&section=4" class="mw-editsection-visualeditor" title="Edit section: Assigning bug reports">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=Project:Bug-wranglers&action=edit&section=4" title="Edit section: Assigning bug reports">edit source</a><span class="mw-editsection-bracket">]</span></span></h3>
<ul><li>Bug reports requesting <b>version bumps</b> should be assigned to the appropriate maintainers directly. Also check the description of the bug for references to security bugs, in which case the bug report should be assigned to <a rel="nofollow" class="external text" href="mailto:security@gentoo.org">security@gentoo.org</a> immediately, using product "Gentoo Security" and component "Vulnerabilities", with the maintainers CC'd.</li>
<li>If a bug report pertains to a specific <b>package</b>, then you enter the package's directory in your copy of the <a rel="nofollow" class="external text" href="https://gitweb.gentoo.org/repo/gentoo.git/">gentoo git repository</a> (or perhaps the online version which should always be more or less up to date) and read the <span style="font-family: monospace; font-size: 95%">metadata.xml</span> file you find there. When <span style="font-family: monospace; font-size: 95%">metadata.xml</span> lists a single maintainer, then you assign the bug to that maintainer. When the file lists multiple entries, then you assign the bug to the first <code><maintainer></code>, and CC the other <code><maintainer></code>(s). If you find that <span style="font-family: monospace; font-size: 95%">metadata.xml</span> lists inappropriate and/or confusing contact information, then make a note of that in a comment on the bug report and assign/CC the bug report as well as you can.</li>
<li>Bug reports about packages in <b>overlays</b> should be assigned to the <code><owner></code> tag in <span style="font-family: monospace; font-size: 95%"><a rel="nofollow" class="external text" href="https://api.gentoo.org/overlays/repositories.xml">repositories.xml</a></span>. Some of these overlays want to get their bugs tracked elsewhere, and explicitly state this in their <code><description></code> tags.</li>
<li>When a bug report calls attention to <b>multiple packages</b>, then things get slightly more complicated. When the listed packages do not belong to the same maintainer or team, for instance when a library upgrade causes several packages to fail to emerge or run, then you should ask the bug reporter to file separate bugs assigned to each set of packages' maintainer(s), and make those bug reports block the original bug report, which then becomes a <b>tracker bug</b> (denoted by the <code>Tracker</code> keyword.</li>
<li>Assign bug reports about <b>eclasses</b> to the eclass maintainer mentioned in the <a rel="nofollow" class="external text" href="https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass">.eclass file</a>.</li>
<li>A <b>keyword request</b> should be assigned to the package's maintainer and CC'd to the appropriate arch team(s). The report's <code>Keywords</code> field should contain the <code>KEYWORDREQ</code> keyword.</li>
<li>A <b>stabilization request</b> should be handled by the package's maintainer, so you should not CC arch teams in your role as bug wrangler, nor set the <code>STABLEREQ</code> keyword in the <code>Keywords</code> field. Unless the package is maintainer-needed, then you should add arches and set the Keyword field if the bug makes sense.</li>
<li>Bug reports that concern <b>profiles</b> should be assigned to <a rel="nofollow" class="external text" href="mailto:qa@gentoo.org">qa@gentoo.org</a> with <a rel="nofollow" class="external text" href="mailto:release@gentoo.org">release@gentoo.org</a> CC'd. Exceptions are profiles that are obviously maintained by some project, like hardened, selinux, prefix, etc. Those get assigned to the maintaining project.</li>
<li>Bug reports that relate to issues other than the portage tree, like problems with Gentoo's Bugzilla, Gentoo infrastructure, mirrors or staffing matters (devrel, userrel and so on) are usually easier to assign. The <code>Product</code> and <code>Component</code> fields of each bug should help you (re)assign these reports appropriately.</li>
<li>Bugs about <b>cross compilation</b> should be assigned to <a rel="nofollow" class="external text" href="mailto:cross@gentoo.org">cross@gentoo.org</a></li>
<li>Bug reports that <b>include patches</b> or other solutions can usually be assigned directly to the maintainers.</li>
<li>If a acct-user related bug is related to a specific package, add both to the summary as in <span class="fa fa-bug fa-fw"></span><a rel="nofollow" class="external text" href="https://bugs.gentoo.org/show_bug.cgi?id=729322">bug #729322</a> and assign to the package maintainer.</li>
<li>Assign bugs which occur on a specific <b>architecture</b> only (arm, arm64, ppc, ...) to the maintainer of the package. The maintainer of the package can ping the arch teams on IRC in order to solve the bug together.</li></ul>
<p><br />
<b>Please contact Bug-wranglers, if we need adjustments on the above agreements.</b>
</p>
<h2><span class="mw-headline" id="Participating">Participating</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Bug-wranglers&veaction=edit&section=5" class="mw-editsection-visualeditor" title="Edit section: Participating">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=Project:Bug-wranglers&action=edit&section=5" title="Edit section: Participating">edit source</a><span class="mw-editsection-bracket">]</span></span></h2>
<p>The best approach to bug wrangling is to really <b>get involved</b> with individual bug reports.
</p>
<ul><li>All users with <a href="/wiki/Editbugs_privilege" title="Editbugs privilege">editbugs privilege</a> on Bugzilla are invited to assign bug reports</li>
<li>Working on bug reports is an exhausting job. Don't try to do <b>everything</b>.</li>
<li>Some bug reports make your blood boil. Ignore them and let someone else handle them.</li>
<li>Be <b>friendly</b>, but <b>not chatty</b>.</li>
<li>Use <b>precise wording</b> that leads to precise answers and a solution.</li>
<li>You can CC yourself to monitor, if you assigned a bug report properly or when you requested information. You can set <b>auto CC</b> in your bugzilla preferences, if you like. You can always un-CC again.</li>
<li><b>Avoid full quotes</b>.</li>
<li>Help to guide to satisfactory <b>solutions</b>.</li></ul>
<p><br />
</p>
<h3><span class="mw-headline" id="Resources">Resources</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Bug-wranglers&veaction=edit&section=6" class="mw-editsection-visualeditor" title="Edit section: Resources">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=Project:Bug-wranglers&action=edit&section=6" title="Edit section: Resources">edit source</a><span class="mw-editsection-bracket">]</span></span></h3>
<ul><li><a href="/wiki/Template:Bug" title="Template:Bug">Bug Template for the Wiki pages</a></li>
<li><a rel="nofollow" class="external text" href="https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&list_id=4592980&namedcmd=Bug%20Wranglers&remaction=run&sharer_id=46764">New unassigned bug tickets</a> which are still assigned to Bugwranglers (also available in your bugzilla Preferences -> Saved Searches)</li>
<li><a rel="nofollow" class="external text" href="https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=active%20TRACKER&sharer_id=85842">Active Tracker Bug Tickets</a> (activity within the last 180 days)</li>
<li>A <a rel="nofollow" class="external text" href="https://github.com/mgorny/bug-assign-user-js">JavaScript plugin</a> for <a rel="nofollow" class="external text" href="https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/">greasemonkey</a> to assign bugs fast and easy.</li>
<li><a rel="nofollow" class="external text" href="https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem&list_id=5172112&namedcmd=m-n%20PATCH&remaction=run">Bugs assigned to <b>maintainer-needed</b> with a <b>PATCH</b></a></li></ul>
<h3><span class="mw-headline" id="History">History</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Bug-wranglers&veaction=edit&section=7" class="mw-editsection-visualeditor" title="Edit section: History">edit</a><span class="mw-editsection-divider"> | </span><a href="/index.php?title=Project:Bug-wranglers&action=edit&section=7" title="Edit section: History">edit source</a><span class="mw-editsection-bracket">]</span></span></h3>
<p>The project was set up after the de-facto resignation of long time <i>Main Bug Wrangler</i> Jakub Moc, when it turned out we required a division of labor to get all bugs properly assigned within an acceptable time frame (from the moment of a bug report's creation to its proper assignment). For his years of relentless bug wrangling, this project both owes him its gratitude and earns its existence.
</p><p><br />
</p>
<hr /><p><small>This page is based on a document formerly found on our main website <a rel="nofollow" class="external text" href="https://www.gentoo.org/">gentoo.org</a>. <br />The following people contributed to the original document: <b>jer</b><br /><span style="color: #555;">They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do <b>not</b> add yourself here; your contributions are recorded on each article's associated history page.</span></small></p>
' |
Unix timestamp of change (timestamp) | 1656562373 |