| 1 |
jer 08/07/23 16:18:51 |
| 2 |
|
| 3 |
Modified: index.xml |
| 4 |
Log: |
| 5 |
Add more policy. Add links, add formatting, finally add assignment policy (thanks to darkside for the poke on IRC). |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.4 xml/htdocs/proj/en/qa/bug-wranglers/index.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?rev=1.4&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?rev=1.4&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?r1=1.3&r2=1.4 |
| 13 |
|
| 14 |
Index: index.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml,v |
| 17 |
retrieving revision 1.3 |
| 18 |
retrieving revision 1.4 |
| 19 |
diff -u -r1.3 -r1.4 |
| 20 |
--- index.xml 14 Jul 2008 19:30:48 -0000 1.3 |
| 21 |
+++ index.xml 23 Jul 2008 16:18:50 -0000 1.4 |
| 22 |
@@ -29,7 +29,8 @@ |
| 23 |
The goal of the Bug Wranglers project is to clarify how new bugs on |
| 24 |
Gentoo's bug tracker should be handled. This document describes the rules to |
| 25 |
bug assignment, CC'ing herd teams, maintainers, the role of metadata.xml and |
| 26 |
-herds.xml, who are bug wranglers and how one should contact them. |
| 27 |
+<uri link="/proj/en/metastructure/herds/herds.xml">herds.xml</uri>, |
| 28 |
+who are bug wranglers and how one should contact them. |
| 29 |
</p> |
| 30 |
</goals> |
| 31 |
|
| 32 |
@@ -42,7 +43,7 @@ |
| 33 |
<title>Bug Wrangling</title> |
| 34 |
|
| 35 |
<section> |
| 36 |
-<title>Checking and Improving Bug Reports</title> |
| 37 |
+<title>Assessing Bug Reports</title> |
| 38 |
<body> |
| 39 |
<p> |
| 40 |
How and when you assign a bug report depends on the type of bug report and the |
| 41 |
@@ -65,25 +66,66 @@ |
| 42 |
should be ASSIGNED to bug-wranglers, and a full build log should be requested |
| 43 |
from the reporter.</li> |
| 44 |
<li>Bug reports that <b>include patches</b> or other solutions accompanying the actual bug description can usually be assigned directly to the maintainers.</li> |
| 45 |
-<li>The Bug Summary uniquely identifies the bug that is being reported. As |
| 46 |
+<li>The <c>Summary</c> uniquely identifies the bug that is being reported. As |
| 47 |
there could be several bugs saying that cat/pkg "failed to emerge", it is |
| 48 |
important to at least replace such generic descriptions of an emerge failing |
| 49 |
with a more exact description, noting the ebuild phase that failed or, better |
| 50 |
yet, the first error message that occured.</li> |
| 51 |
<li>Bug reports that refer to a single or a few (similar) packages should |
| 52 |
-detail the package atom as completely as possible in the Summary. Bug reports |
| 53 |
+detail the package atom as completely as possible in the <c>Summary</c>. Bug reports |
| 54 |
about eclasses should list the full eclass filename.</li> |
| 55 |
</ul> |
| 56 |
</body> |
| 57 |
</section> |
| 58 |
|
| 59 |
-<!-- |
| 60 |
<section> |
| 61 |
<title>Assigning Bug Reports</title> |
| 62 |
<body> |
| 63 |
+<p> |
| 64 |
+To assign a bug report to the right people, you will need to find some more |
| 65 |
+information, depending on the type of bug report. |
| 66 |
+</p> |
| 67 |
+<ul> |
| 68 |
+<li>If a bug report pertains to a specific <b>package</b>, then you enter the |
| 69 |
+package's directory in your copy of the <uri |
| 70 |
+link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/">gentoo-x86 CVS |
| 71 |
+repository</uri> (or perhaps the online version which should always be more or |
| 72 |
+less up to date) and read the <c>metadata.xml</c> file you find there. When |
| 73 |
+<c>metadata.xml</c> lists a single maintainer or herd, then you assign the bug |
| 74 |
+to that maintainer or herd. When the file lists multiple entries, then you |
| 75 |
+assign the bug to the first maintainer, and CC the other maintainer(s) and |
| 76 |
+herd(s).</li> |
| 77 |
+<li>In cases where <c>metadata.xml</c> lists a herd which Gentoo Bugzilla |
| 78 |
+doesn't know about (which it will ask you to correct before it accepts changes |
| 79 |
+to the bug report), you should consult <uri |
| 80 |
+link="/proj/en/metastructure/herds/herds.xml">herds.xml</uri> to figure out the |
| 81 |
+appropriate e-mail alias for that herd.</li> |
| 82 |
+<li>When a bug report calls attention to <b>multiple packages</b>, then things |
| 83 |
+become slightly more complicated. When the listed packages do not belong to the |
| 84 |
+same maintainer or team, for instance when a library upgrade causes several |
| 85 |
+packages to fail to emerge or run, then you should ask the bug reporter to file |
| 86 |
+separate bugs assigned to each set of packages' maintainer(s), and make those |
| 87 |
+bug reports block the original bug report, which then becomes a <b>tracker |
| 88 |
+bug</b> (denoted by the <c>Tracker</c> keyword. Bug reports with many |
| 89 |
+maintainers CC'd are known to bog down and never get resolved. Of course, you |
| 90 |
+should only create a tracker bug when the bug is confirmed and the solution is |
| 91 |
+clear.</li> |
| 92 |
+<li>Bug reports that concern <b>eclasses</b> should be assigned to the eclass |
| 93 |
+maintainer. To figure out who maintains an eclass, browse to the |
| 94 |
+<uri link="http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass">gentoo-x86/eclass</uri> directory, open the file and read who maintains the eclass at the top |
| 95 |
+of the file.</li> |
| 96 |
+<li>A <b>keyword request</b> should be assigned to the package's maintainer and CC'd |
| 97 |
+to the appropriate arch team(s).</li> |
| 98 |
+<li>A <b>stabilisation request</b> should be handled by the package's maintainer, so |
| 99 |
+you should not CC arches in your role as bug wrangler.</li> |
| 100 |
+<li>Bug reports that relate to issues other than the portage tree, like |
| 101 |
+problems with Gentoo's bugzilla, Gentoo infrastructure, mirrors or staffing |
| 102 |
+matters (devrel, userrel and so on) are usually easier to assign. The <c>Product</c> |
| 103 |
+and <c>Component</c> fields of each bug should help you (re)assign these reports |
| 104 |
+appropriately.</li> |
| 105 |
+</ul> |
| 106 |
</body> |
| 107 |
</section> |
| 108 |
---> |
| 109 |
|
| 110 |
</extrachapter> |
| 111 |
|
| 112 |
@@ -91,9 +133,11 @@ |
| 113 |
<title>Participating</title> |
| 114 |
<section> |
| 115 |
<body> |
| 116 |
-<p>All Gentoo developers who can change the Assignee fields of new bugs, are |
| 117 |
+<p> |
| 118 |
+Any Gentoo developers who can change the <c>Assignee</c> fields of new bugs are |
| 119 |
welcome to help assign bugs to the right developers. Most developers will |
| 120 |
-appreciate it if, while doing so, you follow the rules layed out above.</p> |
| 121 |
+appreciate it if, while doing so, you follow the rules layed out above. |
| 122 |
+</p> |
| 123 |
</body> |
| 124 |
</section> |
| 125 |
</extrachapter> |
Archives