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

[Sven Vermeulen]

swift       08/05/23 20:42:42

  Modified:             bugzilla-howto.xml
  Log:
  Coding style

Revision  Changes    Path
1.13                 xml/htdocs/doc/en/bugzilla-howto.xml

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml?rev=1.13&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml?rev=1.13&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml?r1=1.12&r2=1.13

Index: bugzilla-howto.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- bugzilla-howto.xml	1 Feb 2008 19:30:40 -0000	1.12
+++ bugzilla-howto.xml	23 May 2008 20:42:42 -0000	1.13
@@ -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/bugzilla-howto.xml,v 1.12 2008/02/01 19:30:40 jkt Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml,v 1.13 2008/05/23 20:42:42 swift Exp $ -->
 
 <guide link="/doc/en/bugzilla-howto.xml">
 <title>Gentoo Bug Reporting Guide</title>
@@ -201,7 +201,7 @@
 
 <note>
 One can also debug with core dumps. These core files contain the same
-information that the program would produce when run with gdb.  In order to debug
+information that the program would produce when run with gdb. In order to debug
 with a core file with bad_code, you would run <c>gdb ./bad_code core</c> where
 core is the name of the core file.
 </note>
@@ -327,11 +327,11 @@
 </pre>
 
 <p>
-This ends the walk-through of <c>gdb</c>. Using <c>gdb</c>, we 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>, we 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>
@@ -350,9 +350,9 @@
 tool called <c>strace</c> was created to help deal with this. <c>strace</c>
 traces system calls (hence the name) which include calls that use the memory and
 files. For our example, we're going to take a program foobar2. This is an
-updated version of foobar. However, during the change over to foobar2, you notice
-all your configurations are missing!  In foobar version 1, you had it setup to
-say "foo", but now it's using the default "bar".
+updated version of foobar. However, during the change over to foobar2, you
+notice all your configurations are missing!  In foobar version 1, you had it
+setup to say "foo", but now it's using the default "bar".
 </p>
 
 <pre caption="Foobar2 With an invalid configuration">
@@ -454,9 +454,9 @@
 </pre>
 
 <p>
-The program is compiling smoothly when it suddenly stops and presents an error message. This
-particular error can be split into 3 different sections, The compile messages, the build
-error, and the emerge error message as shown below.
+The program is compiling smoothly when it suddenly stops and presents an error
+message. This particular error can be split into 3 different sections, The
+compile messages, the build error, and the emerge error message as shown below.
 </p>
 
 <pre caption="Parts of the error">
@@ -658,8 +658,8 @@
 </p>
 
 <p>
-Comment is the important part. Use the comment field to list what appears to be a
-specific instance of the error. Basically, don't use anything like the
+Comment is the important part. Use the comment field to list what appears to be
+a specific instance of the error. Basically, don't use anything like the
 beginning of the build error, find a line that's before it stating a true
 error. Also, you'll want to filter out any punctuation to prevent bugzilla
 from interpreting the results the comment the wrong way. Example from the xclass
@@ -772,9 +772,9 @@
 <note>
 We would rather see a bug whose product was not supposed to be Gentoo Linux but
 has been filed under the same rather than seeing a bug which belongs the Gentoo
-Linux product and filed elsewhere. While neither is preferred, the former is more
-acceptable and understandable (except website bugs.. we might have an issue with
-that...).
+Linux product and filed elsewhere. While neither is preferred, the former is
+more acceptable and understandable (except website bugs.. we might have an issue
+with that...).
 </note>
 
 <p>
@@ -934,7 +934,7 @@
     Minor - Your program crashes here and there with apparent workarounds.
   </li>
   <li>
-    Normal - The default.  If you're not sure leave it here unless it's a new
+    Normal - The default. If you're not sure leave it here unless it's a new
     build or cosmetic change, then read below for more information.
   </li>
   <li>Trivial - Things such as a mispelled word or whitespace clean up. </li>
@@ -1182,7 +1182,7 @@
 
 <p>
 The documentation team will require the flag combination <b>-Nt</b> as well as
-<b>-u</b>. This mainly has to do with tab expansion.  You can create such a diff
+<b>-u</b>. This mainly has to do with tab expansion. You can create such a diff
 with:
 </p>
 
@@ -1251,7 +1251,7 @@
 Now shortly afterward, we find the error in the strace log and fix the bug and
 mark it as RESOLVED FIXED and mention 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 shown the following.
+it. The bug now becomes resolved, and you are shown the following.
 </p>
 
 <figure link="/images/docs/bugzie-reso.png" caption="Resolved Bug"/>
@@ -1282,7 +1282,7 @@
   </li>
   <li>
     CANTFIX - Somehow the bug cannot be solved because of certain
-    circumstances.  These circumstances will be noted by the person taking the
+    circumstances. These circumstances will be noted by the person taking the
     bug.
   </li>
   <li>
@@ -1303,7 +1303,7 @@
 
 <p>
 Sometimes, before the bug can be resolved, a developer may request that you
-test an updated ebulid.  In the next chapter we'll take a look at testing
+test an updated ebulid. In the next chapter we'll take a look at testing
 ebuilds.
 </p>
 
@@ -1422,7 +1422,7 @@
 <p>
 In the first section we see that the emerge started off as it should. The second
 section shows our patch being applied successfully by the "[ ok ]" status
-message to the right. The last section tells us the program compiled ok.  The
+message to the right. The last section tells us the program compiled ok. The
 patch works! Now we can go and let the developer know that their patch works
 fine, and that they can commit the fix to portage.
 </p>



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