Adding upstream version 2:4.17.12+dfsg.upstream/2%4.17.12+dfsgupstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 112 insertions, 0 deletions

diff --git a/docs-xml/Samba-Developers-Guide/contributing.xml b/docs-xml/Samba-Developers-Guide/contributing.xml
new file mode 100644
index 0000000..af21b6e
--- /dev/null
+++ b/docs-xml/Samba-Developers-Guide/contributing.xml
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+
+<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>
+		</listitem>
+	</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>
+		<itemizedlist>
+		<listitem><para>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.</para></listitem>
+		<listitem><para>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.</para></listitem>
+		<listitem><para>Don't put separate 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. </para></listitem>
+		<listitem><para>Make sure your patch complies to the samba coding style as
+		suggested in the coding-suggestions chapter. </para></listitem>
+			</itemizedlist>
+		</para>
+		</listitem>
+	</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@lists.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>