This commit was manufactured by cvs2svn to create branch 'SAMBA_3_0'.

diff --git a/docs/docbook/devdoc/contributing.xml b/docs/docbook/devdoc/contributing.xml
new file mode 100644 (file)
index 0000000..d0fb1d4
--- /dev/null
+++ b/docs/docbook/devdoc/contributing.xml
@@ -0,0 +1,106 @@
+<chapter id="contributing">
+<chapterinfo>
+       &author.jelmer;
+</chapterinfo>
+
+<title>Contributing code</title>
+
+<para>Here are a few tips and notes that might be useful if you are 
+       interested in modifying samba source code and getting it into 
+       samba's main branch.</para>
+
+<variablelist>
+       <varlistentry>
+               <term>Retrieving the source</term>
+
+               <listitem>
+               <para>In order to contribute code to samba, make sure you have the 
+                       latest source. Retrieving the samba source code from CVS is 
+                       documented in the appendix of the Samba HOWTO Collection.
+               </para>
+               </listitem>
+       </varlistentry>
+
+       <varlistentry>
+               <term>Discuss large modifications with team members</term>
+               <listitem>
+               <para>Please discuss large modifications you are going to make 
+               with members of the samba team. Some parts of the samba code 
+               have one or more 'owners' - samba developers who wrote most 
+               of the code and maintain it. 
+               </para>
+
+               <para>This way you can avoid spending your time and effort on 
+               something that is not going to make it into the main samba branch 
+               because someone else was working on the same thing or because your 
+               implementation is not the correct one.
+               </para>
+       </varlistentry>
+
+       <varlistentry>
+               <term>Patch format</term>
+               <listitem>
+               <para>Patches to the samba tree should be in unified diff format, 
+                       e.g. files generated by <userinput>diff -u</userinput>. 
+               </para>
+
+               <para>If you are modifying a copy of samba you retrieved from CVS, 
+               you can easily generate a diff file of these changes by running 
+               <userinput>cvs diff -u</userinput>.</para>                      
+               </listitem>
+       </varlistentry>
+
+       <varlistentry>
+               <term>Points of attention when modifying samba source code</term>
+               <listitem><para>
+               <simplelist>
+               <member>Don't simply copy code from other places and modify it until it
+               works. Code needs to be clean and logical. Duplicate 
+               code is to be avoided.</member>
+               <member>Test your patch. It might take a while before one of us looks 
+               at your patch so it will take longer before your patch when your patch 
+               needs to go thru the review cycle again.</member>
+               <member>Don't put seperate patches in one large diff file. This makes 
+               it harder to read, understand and test the patch. You might 
+               also risk not getting a good patch committed because you mixed it 
+               with one that had issues. </member>
+               <member>Make sure your patch complies to the samba coding style as 
+               suggested in the coding-suggestions chapter. </member>
+               </simplelist>
+       </varlistentry>
+
+       <varlistentry>
+               <term>Sending in bugfixes</term>
+               <listitem>
+               <para>Bugfixes to bugs in samba should be submitted to samba's
+               <ulink url="https://bugzilla.samba.org/">bugzilla system</ulink>, 
+               along with a description of the bug.
+               </para>
+               </listitem>
+       </varlistentry>
+
+       <varlistentry>
+               <term>Sending in feature patches</term>
+               <listitem>
+               <para>Send feature patches along with a description of what the 
+               patch is supposed to do to the 
+               <ulink url="mailto:samba-technical@samba.org">Samba-technical mailinglist</ulink> and possibly to a samba team member who is (one of the) 'owners'
+               of the code you made modifications to. We are all busy people 
+               so everybody tends to 'let one of the others handle it'. If nobody 
+               responded to your patch for a week, try to send it again until you 
+               get a response from one of us.
+               </para></listitem>
+       </varlistentry>
+
+       <varlistentry>
+               <term>Feedback on your patch</term>
+               <listitem>
+               <para>One of the team members will look at your patch and either 
+               commit your patch or give comments why he won't apply it. In the 
+               latter case you can fix your patch and re-send it until 
+               your patch is approved.</para>
+               </listitem>
+       </varlistentry>
+</variablelist>
+
+</chapter>