[gentoo-doc-cvs] cvs commit: bugzilla-howto.xml

[Shyam Mani]

fox2mike    05/07/07 11:24:54

  Modified:    xml/htdocs/doc/en/draft bugzilla-howto.xml
  Log:
  Few more minor changes.

Revision  Changes    Path
1.2       +26 -26    xml/htdocs/doc/en/draft/bugzilla-howto.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/bugzilla-howto.xml?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/bugzilla-howto.xml?rev=1.2&content-type=text/plain&cvsroot=gentoo
diff : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/draft/bugzilla-howto.xml.diff?r1=1.1&r2=1.2&cvsroot=gentoo

Index: bugzilla-howto.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/bugzilla-howto.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- bugzilla-howto.xml	7 Jul 2005 11:07:05 -0000	1.1
+++ bugzilla-howto.xml	7 Jul 2005 11:24:54 -0000	1.2
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/bugzilla-howto.xml,v 1.1 2005/07/07 11:07:05 fox2mike Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/draft/bugzilla-howto.xml,v 1.2 2005/07/07 11:24:54 fox2mike Exp $ -->
 
 <guide link="/doc/en/bugzilla-howto.xml">
 <title>Gentoo Bug Reporting Guide</title>
@@ -187,7 +187,7 @@
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
-There is absolutely no warranty for GDB.sType "show warranty" for details.
+There is absolutely no warranty for GDB. Type "show warranty" for details.
 This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
 </pre>
 
@@ -213,7 +213,8 @@
 program, making it hard for developers to find which one is causing the issue.
 In order to help them out, we do what's called a backtrace. A backtrace runs
 backwards through all the functions that occurred upon program execution, to the
-function at fault. To get a backtrace, at the (gdb) prompt, type in <c>bt</c>.
+function at fault. Functions that return (without causing a crash) will not show
+up on the backtrace. To get a backtrace, at the (gdb) prompt, type in <c>bt</c>.
 You will get something like this:
 </p>
 
@@ -308,11 +309,11 @@
 </pre>
 
 <p>
-This ends the walk-through of gdb. Using gdb, it is my hope that you will be
-able to use it to create better bug reports. However, there are other types of
-errors that can cause a program to fail during run time. One of the other ways
-is through improper file access. We can find those using a nifty little tool
-called <c>strace</c>.
+This ends the walk-through of <c>gdb</c>. Using <c>gdb</c>, I hope that you will
+be able to use it to create better bug reports. However, there are other types
+of errors that can cause a program to fail during run time. One of the other
+ways is through improper file access. We can find those using a nifty little
+tool called <c>strace</c>.
 </p>
 
 </body>
@@ -373,10 +374,10 @@
 
 <p>
 Aha! So There's the problem. Someone moved the configuration directory to
-.foobar2 instead of .foobar. We also see the program reading in "bar" as it
-should. In this case, we can recommend the ebuild maintainer to put a warning
-about it. For now though, we can copy over the config file from .foobar and
-modify it to produce the correct results. 
+<path>.foobar2</path> instead of <path>.foobar</path>. We also see the program
+reading in "bar" as it should. In this case, we can recommend the ebuild
+maintainer to put a warning about it. For now though, we can copy over the
+config file from .foobar and modify it to produce the correct results. 
 </p>
 
 </body>
@@ -778,7 +779,7 @@
 "Meta-distribution", it can run on other os's besides Linux. Examples are
 Gentoo on MacOS, Gentoo on FreeBSD, etc. For this example, we'll select All, as
 this can occur on all types of systems. Build Identifier is what is being used
-to report the bugs (for logging purposes).sYou can just leave this as is. Let's
+to report the bugs (for logging purposes).You can just leave this as is. Let's
 see what we have so far:
 </p>
 
@@ -875,13 +876,12 @@
 <figure link="/images/docs/bugzie-new-details.png" caption="New Bug Details"/>
 
 <p>
-Now as you can see, the bug has been assigned to bug-wranglers [at] gentoo
-[dot] org. This is the default location for Application component bugs. However,
-bug-wranglers (usually) won't fix our bugs, so we'll reassign it to someone that
-can (you can let bug-wranglers re-assign it for you as well). For this we use
-the package's metadata.xml. You can normally find them in
-/usr/portage/category/package/metadata.xml. Here's one I've made up for 
-foobar2:
+Now as you can see, the bug has been assigned to bug-wranglers@g.o. This
+is the default location for Application component bugs. However, bug-wranglers
+(usually) won't fix our bugs, so we'll reassign it to someone that can (you can
+let bug-wranglers re-assign it for you as well). For this we use the package's
+metadata.xml. You can normally find them in
+/usr/portage/category/package/metadata.xml. Here's one I've made up for foobar2:
 </p>
 
 <pre caption="metadata.xml">
@@ -901,21 +901,21 @@
 
 <p>
 Notice the maintainer section.T his lists the maintainer of the package, which
-in this case is myself, Chris White. The email listed is chriswhite [at] gentoo
-[dot] org. We will use this to re-assign the bug to the proper person. To do
-this, click the bubble next to Reassign bug to, then fill in the email:
+in this case is myself, Chris White. The email listed is chriswhite@g.o.
+We will use this to re-assign the bug to the proper person. To do this, click
+the bubble next to Reassign bug to, then fill in the email:
 </p>
 
 <note>
 A package without a metadata.xml file should be re-assigned to
-maintainer-needed [at] gentoo [dot] org.
+maintainer-needed@g.o.
 </note>
 
 <figure link="/images/docs/bugzie-reassign.png" caption="Bug Reassignment"/>
 
 <p>
 Then hit the Commit button for the changes to take place. The bug has been
-reassigned to me. Shortly afterwards, you notice (by email usually) that I've
+reassigned to me. Shortly afterward, you notice (by email usually) that I've
 responded to your bug. I've stated that I'd like to see an strace log to figure
 out how the program is trying to access your configuration file. You follow the
 previous instructions on using strace and obtain an strace log. Now you need to
@@ -988,7 +988,7 @@
 </ul>
 
 <p>
-Now shortly afterward, I find the error in the strace log.sI resolve the bug
+Now shortly afterward, I find the error in the strace log. I resolve the bug
 as RESOLVED FIXED and say that there was a change in the location of
 configuration files, and that I will update the ebuild with a warning about it.
 The bug now becomes resolved, and you are displayed with this:
@@ -1038,7 +1038,7 @@
 This concludes the howto on working with Bugzilla. I hope you find this useful.
 If you have any questions, comments, or ideas regarding this document, please
 send them to me at <mail
-link="chriswhite@g.o">chriswhite [at] gentoo [dot] org</mail>. Special
+link="chriswhite@g.o">chriswhite@g.o</mail>. Special
 thanks go to moreon for his notes on -g flags and compile errors, the people at
 #gentoo-bugs for helping out with bug-wrangling, and Griffon26 for his notes on
 maintainer-needed.



-- 
gentoo-doc-cvs@g.o mailing list