| 1 |
jer 12/05/30 14:28:43 |
| 2 |
|
| 3 |
Modified: index.xml |
| 4 |
Log: |
| 5 |
Add more guidelines about the format of the Summary. |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.26 xml/htdocs/proj/en/qa/bug-wranglers/index.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?rev=1.26&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?rev=1.26&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml?r1=1.25&r2=1.26 |
| 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.25 |
| 18 |
retrieving revision 1.26 |
| 19 |
diff -u -r1.25 -r1.26 |
| 20 |
--- index.xml 18 May 2012 04:30:25 -0000 1.25 |
| 21 |
+++ index.xml 30 May 2012 14:28:43 -0000 1.26 |
| 22 |
@@ -79,14 +79,13 @@ |
| 23 |
How and when you assign a bug report depends on the type of bug report as well as |
| 24 |
correctness and completeness of the bug report. |
| 25 |
</p> |
| 26 |
-<ul> |
| 27 |
-<li>Bug reports requesting <b>version bumps</b> should be assigned to |
| 28 |
+<p>Bug reports requesting <b>version bumps</b> should be assigned to |
| 29 |
the appropriate maintainers directly. Also check the description of the |
| 30 |
bug for references to security bugs, in which case the bug report should |
| 31 |
be assigned to <mail link="security@g.o">security@g.o</mail> |
| 32 |
immediately, using product "Gentoo Security" and component "Vulnerabilities", |
| 33 |
-with the maintainers CC'd.</li> |
| 34 |
-<li>Bug reports that say something isn't working or compiling <b>without a |
| 35 |
+with the maintainers CC'd.</p> |
| 36 |
+<p>Bug reports that say something isn't working or compiling <b>without a |
| 37 |
comprehensive analysis of the causes</b>, should contain at least the output of |
| 38 |
`emerge --info' as well as a thorough description of the problem, including |
| 39 |
error output (or expected versus actual output), the command that led to the |
| 40 |
@@ -94,23 +93,25 @@ |
| 41 |
issue. It is customary to only assign a bug report once these requirements have |
| 42 |
been fulfilled. If the reporter hasn't fulfilled these requirements, the bug |
| 43 |
should be marked <c>ASSIGNED</c> to bug-wranglers, and a full build log should |
| 44 |
-be requested from the reporter.</li> |
| 45 |
-<li>Bug reports that <b>include patches</b> or other solutions accompanying |
| 46 |
-the actual bug description can usually be assigned directly to the maintainers.</li> |
| 47 |
-<li>The <c>Summary</c> uniquely identifies the bug that is being reported. As |
| 48 |
+be requested from the reporter.</p> |
| 49 |
+<p>Bug reports that <b>include patches</b> or other solutions accompanying |
| 50 |
+the actual bug description can usually be assigned directly to the maintainers.</p> |
| 51 |
+<p>The <c>Summary</c> uniquely identifies the bug that is being reported. As |
| 52 |
there could be several bugs saying that cat/pkg "failed to emerge", it is |
| 53 |
important to at least replace such generic descriptions of an emerge failing |
| 54 |
with a more exact description, noting the ebuild phase that failed or, better |
| 55 |
-yet, the first error message that occured.</li> |
| 56 |
-<li>Bug reports that refer to a single or a few (similar) packages should |
| 57 |
+yet, the first error message that occured.</p> |
| 58 |
+<p>Bug reports that refer to a single or a few (similar) packages should |
| 59 |
detail the <b>package atom(s)</b> as completely as possible (at least the |
| 60 |
-CATEGORY/PKG(s)) in the <c>Summary</c>, including a version only when other |
| 61 |
-versions do not exhibit the bug. Also note that CATEGORY/PKG[-VERSION].ebuild |
| 62 |
-is never a valid atom - either refer to CATEGORY/PKG/PKG[-VERSION].ebuild or |
| 63 |
-simply remove the .ebuild suffix entirely.</li> |
| 64 |
-<li>Bug reports about <b>eclasses</b> should list the full eclass filename in the |
| 65 |
-<c>Summary</c>.</li> |
| 66 |
-</ul> |
| 67 |
+CATEGORY/PKG(s)) at the start of the <c>Summary</c>. If the ebuild is from an |
| 68 |
+overlay, the name of the overlay should be prefixed at the start in square |
| 69 |
+brackets. The atom should include a version only when other versions do not |
| 70 |
+exhibit the bug. Also note that CATEGORY/PKG[-VERSION].ebuild is never a valid |
| 71 |
+atom - either refer to CATEGORY/PKG/PKG[-VERSION].ebuild or simply remove the |
| 72 |
+.ebuild suffix entirely.</p> |
| 73 |
+<pre caption="The standard format of the Summary">[name overlay] CATEGORY/PKG(-version(-revision)) - problem description</pre> |
| 74 |
+<p>Bug reports about <b>eclasses</b> should list the full eclass filename in the |
| 75 |
+<c>Summary</c> instead of an atom.</p> |
| 76 |
</body> |
| 77 |
</section> |
Archives