Update to patches sgml

[Tony Lambregts]

In an effort to start a flame war <g> I decided to add a few notes about 
style to patches.sgml and while I was at it I added a note about being 
able to submit non cvs patches.

Change Log: add note about submitting non cvs patches and notes about 
programing syles.

File: documentation/patches.sgml

-- 

Tony Lambregts

-------------- next part --------------
Index: patches.sgml
===================================================================
RCS file: /home/wine/wine/documentation/patches.sgml,v
retrieving revision 1.4
diff -u -r1.4 patches.sgml
--- patches.sgml	17 Sep 2002 00:07:03 -0000	1.4
+++ patches.sgml	19 Dec 2002 00:04:53 -0000
@@ -47,6 +47,74 @@
       <para>
         For removals, list the files.
       </para>
+      <para>
+        Since wine is constantly changing due to development it is strongly
+        recomended that you use cvs for patches, if you cannot use cvs for
+        some reason, you can submit patches against the latest tarball. 
+        To do this make a copy of the files that you will be modifying and
+        <command>diff -u</command> against the old file. I.E.
+      </para>
+      <screen>
+diff -u file.old file.c > file.txt
+      </screen>
+    </sect1>
+
+    <sect1 id="Style-notes">
+      <title>Some notes about style</title>
+       
+      <para>
+        There are a few conventions that about coding style that have 
+        adopted over the years of development. The rational for these <quote>
+        rules</quote> is explained for each one.
+      </para>
+      <itemizedlist>
+        <listitem>
+        <para>
+          Tabs are not forbidden but are defined as 8 charaters and the usual
+          amount of indentation is 4 characters. 
+        </para>
+        </listitem>
+        <listitem>
+        <para>
+          C++ style comments are discouraged since some compilers choke on 
+          them.
+        </para>
+        </listitem>
+        <listitem>
+        <para>
+          Commenting out a block of code is usually done by enclosing it in 
+          <command>#if 0 ... #endif</command> Statements. For example.
+        </para>
+        <screen> 
+
+/* note about reason for commenting block */
+#if 0
+code
+code /* comments */
+code
+#endif
+        </screen>
+        <para>
+          The reason for using this method is that it does not require that
+          you edit comments that may be inside the block of code.
+        </para>
+        </listitem>
+        <listitem>
+        <para>
+          Patches should be attached so that they can be read inline. This 
+          may mean some more work for you. However it allows others to review
+          your patch easily and increase the chances of it not being 
+          overlooked or forgotten.
+        </para>
+        </listitem>
+        <listitem>
+        <para>
+          Code is usually limited to 80 columns. This helps prevent mailers
+          mangling patches by line wrap. Also it generally makes code easier
+          to read.
+        </para>
+        </listitem>
+      </itemizedlist>
     </sect1>
 
     <sect1 id="patch-quality">